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ABSTRACT 


The  Maritime  Operations  Centers  (MOCs)  are  an  integral  part  of  the  Navy’s  Maritime 
Headquarters  (MHQ)  eoncept  for  Command,  Control,  Communieations,  Computers, 
Intelligenee,  Surveillance  and  Reconnaissance  (C4ISR)  structure.  The  purpose  of  this 
study  was  to  determine  if  the  mission  of  the  MOC  could  be  accomplished  with  the 
existing  C4I  systems  assigned.  By  tracing  functions  to  systems,  gaps  were  identified 
which  created  a  foundation  to  investigate  whether  systems  currently  in  development  were 
available  to  meet  these  gaps.  In  some  cases,  candidate  C4I  systems  were  proposed  to  fill 
gaps.  System  functionality  overlap  was  also  noted. 

As  a  by-product  of  our  research  into  the  MOC  concept  and  analysis  of  its  required 
functions  and  candidate  component  systems,  we  have  proposed  a  methodology  for  future 
work  in  the  design  of  the  MOC  architecture.  Through  the  use  of  requirements  analysis 
tools,  we  have  been  able  to  structure  the  requirements,  functions  and  proposed  systems  of 
the  MOC  architecture  in  a  way  that  automates  the  tasks  of  functional  analysis  and  system 
architecture  design.  Future  work  on  the  MOC  requirements  and  architectures  should 
utilize  these  or  similar  automation. 
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EXECUTIVE  SUMMARY 


The  Maritime  Headquarters  with  Maritime  Operations  Center  (MHQ  with  MOC)  coneept 
was  envisioned  as  a  way  for  the  Navy  to  standardize  the  command  structure  in  order  to 
support  naval,  joint,  and  multinational  roles  and  responsibilities  at  an  operational  level 
while  maintaining  the  flexibility  to  act  as  Navy  component  commanders.  Navy  forces 
commanders,  joint  force  maritime  component  commanders  (JFMCC),  and  joint  task  force 
commanders  (JTF  CDR).  Before  the  MHQ  concept,  operational-level  commands  each 
had  differing  processes  and  procedures  on  how  to  transition  between  operational  roles, 
with  ad-hoc  training  occurring  as  roles  were  assigned.  The  MHQ  with  MOC  concept 
allows  for  a  standard  baseline  of  processes  and  procedures  for  managing  fleet  forces  and 
conducting  operations  with  trained  personnel  able  to  execute  tasks  in  any  of  several 
MHQs  across  the  globe. 


The  MOC,  with  a  standard  baseline  of  Command,  Control,  Communications,  Computers 
and  Intelligence  (C4I)  component  systems,  is  essential  to  the  scalable,  orderly 
management  of  the  operational  activities  of  the  MHQ.  The  MOC  houses  the  tools  that 
the  MHQ  requires  to  execute  its  mission,  providing  collaboration  tools,  communications, 
situational  awareness,  and  command  and  control  utilities.  These  tools  enable  the  MHQ  to 
assess,  plan,  and  execute  the  operational  objectives  of  the  MHQ  commander.  The  MOC 
consists  of  both  land-based  elements  within  the  MHQ  and  forward  shipboard  elements 
for  responses  to  areas  of  crisis. 


A  C4I  baseline  of  MOC  systems  has  been  proposed  by  the  Program  Executive  Office  for 
C4I  (PEO  C4I).  It  is  encompassed  in  a  Spiral  approach  to  fielding,  with  full  capabilities 
estimated  in  Fiscal  Years  2012-2015.  Spiral  8  consisted  of  the  fielding  of  the  majority  of 
existing  C4I  systems  for  Command  and  Control  including  the  Global  Command  and 
Control  System  (GCCS)  Family  of  Systems  including  Maritime  (M);  Integrated  Imagery 
and  Intelligence  (13);  and  Joint  (J).  Spiral  10  provided  additional  networking  capabilities 


XV 


and  upgrades  to  the  MOC  systems.  Further  Spirals  will  bring  the  MOC  in  line  with 
Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES)  and  incorporate  items 
from  Maritime  Domain  Awareness  (MDA)  Spirals  as  those  capabilities  become 
available. 


As  the  architecture  of  the  MOC  was  developed  according  to  the  Department  of  Defense 
Architecture  Framework  (DoDAF),  the  process  flows  of  the  MOC  were  documented  in  a 
set  of  architecture  artifacts.  Documents  contained  lists  of  operational  activities  and  tasks 
required  for  their  completion.  To  ensure  these  tasks  and  activities  would  be  covered  by 
the  recommended  C4I  systems,  it  was  necessary  to  trace  the  process  flows  to  the 
component  system  level  and  observe  gaps  and  overlaps  in  how  the  required  tasks  were 
accomplished. 


Utilizing  architecture  design  software  tools,  we  were  able  to  trace  the  originating 
requirements  from  items  in  the  Universal  Joint  Task  Lists  (UJTL)  to  the  component 
system  level.  The  use  of  automated  tools  is  highly  recommended  for  future  work  on 
MOC  requirements  as  it  allowed  for  concise  graphical  displays  of  the  functions  of  the 
MOC  and  easy  identification  of  gaps  in  the  capabilities  of  available  systems.  It  also 
allowed  for  construction  of  system  views  and  other  architecture  products  from  a  common 
database. 


The  results  of  our  analysis  found  several  areas  where  gaps  existed,  meaning  that  currently 
available  C4I  systems  were  unable  to  meet  the  required  tasks  of  the  MOC.  In  some  cases 
the  activity  was  described  in  earlier  documents  as  being  completed  solely  through  the  use 
of  a  computerized  tool,  but  the  team’s  analysis  determined  it  to  require  more  specialized 
work  with  human  involvement. 
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This  report  is  organized  into  five  main  sections.  Section  I,  the  introduction,  describes  the 
MHQ  with  MOC  concept  origins  and  background  for  this  project,  with  a  breakdown  of 
the  MOC  core  processes.  Section  II  describes  the  research  conducted  by  the  group  for  the 
production  of  this  work  and  the  completion  or  our  tasking.  Section  III  describes  the 
methodology  applied  to  our  work  and  the  systems  engineering  approach  used  in  this 
project.  Section  IV  provides  the  validation  of  the  methodology  through  the  analysis  of 
the  core  process  flows  and  component  systems.  The  final  section  provides  a  summary, 
conclusions,  and  recommendations  for  future  analysis  of  the  MOC  concept. 
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1  INTRODUCTION 


l.I  PROBLEM  STATEMENT 

Operations  conducted  over  the  past  decade  have  identified  gaps  in  the  Navy’s  Command 
and  Control  (C2)  capabilities  needed  to  support  modem  Navy  doctrine.  Naval  combatant 
operations,  joint  operations,  and  humanitarian  relief  missions  have  been  severely 
hampered  by  these  shortfalls.  Capabilities  that  have  exhibited  limitations  include  the 
following: 

•  Ability  to  command  in  a  dynamic  environment. 

•  Ability  to  rapidly  identify  necessary  participants  or  communities  of 
interest  across  echelons  for  planning  and  response  to  crisis  action. 

•  Ability  to  efficiently  collaborate  and  receive  rapid  feedback  to  assess  and 
adapt  to  emerging  conditions  and  shortened  planning/execution  timelines. 
(U.S.  Fleet  Forces  Command,  2007) 

The  Navy’s  answer  to  these  shortfalls  is  the  establishment  of  Maritime  Headquarters  with 
Maritime  Operations  Centers  (MHQ  w/  MOC)  to  effectively  execute  the  necessary 
operational  missions  while  eliminating  the  identified  C2  gaps.  The  standup  of  the  MOCs 
was  the  first  step  in  this  process,  but  non-standardized  systems  and  procedures  have 
contributed  to  some  of  the  gaps  that  were  to  have  been  eliminated.  Commanders  utilized 
the  systems  already  present  or  individually  acquired  systems  from  PEOs  that  partially 
fulfilled  some  identified  mission  requirements.  There  was  little  or  no  consideration  for 
interoperability  between  systems  within  or  between  MOCs  and  no  System  of  Systems 
analysis  has  been  conducted  to  identify  the  complete  set  of  functions  or  requirements  the 
MOCs  must  perform.  These  are  essential  steps  in  the  process  of  designing  and 
implementing  MOCs  that  will  efficiently  and  effectively  conduct  the  required  missions. 


1 


1.2  CAPSTONE  PROJECT  DESCRIPTION 


System  analysis  tools  were  used  to  identify  gaps  and  overlaps  in  capabilities  by  tracing 
the  MOC  architecture  to  the  component  level.  Through  the  use  of  the  tools,  the  tasks  as 
described  in  the  Universal  Joint  Task  Lists  (UJTL)  were  mapped  to  the  MOC  functions 
and  the  individual  Command,  Control,  Communications,  Computer  and  Intelligence 
(C4I)  component  systems  identified  to  execute  those  functions.  Systems  planned  for  the 
MOC  Spiral  8  and  Spiral  10  baselines  were  examined  to  determine  whether  they  were 
able  to  accomplish  the  functional  requirements.  Where  no  component  systems  were  able 
to  sufficiently  meet  the  requirement,  gaps  were  noted.  Similarly,  where  several  systems 
meet  the  same  requirements,  the  overlap  was  noted.  Issues  discovered  during  the 
analysis  regarding  tasks  assigned  to  the  MOC  are  described  in  detail  in  Section  4. 


In  an  effort  to  apply  a  systems  engineering  approach  to  our  work  with  the  MOC  concept, 
different  approaches  to  systems  engineering  were  compared  for  consideration.  The 
“variations”  listed  in  Blanchard  and  Fabry cky  (2006)  provided  several  approaches  that 
could  be  appropriate,  but  the  one  selected  to  support  the  development  of  the  MOC 
concept  was  quoted  by  Blanchard  and  Fabrycky  from  the  Department  of  Defense  (DoD) 
Regulation  5000.2-R  of  2002.  The  definition  quoted  by  Blanchard  and  Fabrycky  is  as 
follows: 


An  approach  to  translate  operational  needs  and  requirements  into  operationally 
suitable  blocks  of  systems.  The  approach  shall  consist  of  top-down,  iterative 
process  of  requirements  analysis,  functional  analysis  and  allocation,  design 
synthesis  and  verification,  and  system  analysis  and  control.  Systems  engineering 
shall  permeate  design,  manufacturing,  test  and  evaluation,  and  support  of  the 
product.  Systems  engineering  principles  shall  influence  the  balance  between 
performance,  risk,  cost  and  schedule  (Blanchard  &  Fabrycky,  2006). 
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Inconsistencies  with  applying  this  approaeh  have  been  identified  in  both  previous  and 
ongoing  Navy  efforts  to  develop  the  MOC  coneept.  Regardless  of  the  approaeh  that  was 
ehosen  for  the  MOC  development,  the  “common  threads”  of  systems  engineering  present 
in  all  definitions  appear  to  be  laeking.  Blanchard  and  Fabrycky  also  cite  some  of  the 
“speeial  areas  of  emphasis”  that  should  be  noted  in  eondueting  systems  engineering. 
They  state: 

A  better  and  more  complete  effort  is  required  regarding  the  initial  definition  of 
systems  requirements,  relating  these  requirements  to  specific  design  criteria,  and 
the  follow-on  analysis  effort  to  ensure  the  effectiveness  of  early  decision  making 
in  the  design  process.  The  true  system  requirements  need  to  be  well  defined  and 
specified,  and  the  traceability  of  these  requirements  from  the  system  level 
downward  needs  to  be  visible  (Blanchard  &  Fabrycky,  2006). 


The  laek  of  requirements  traeeability  for  the  proeess  flows  of  the  MOC,  as  defined  in  the 
currently  available  operational  event- trace  description  (OV-6c)  and  other  documents,  as 
well  as  an  absenee  of  approved  formal  doeumentation  on  whieh  to  base  future,  lower- 
level  system  design,  has  resulted  in  the  inability  to  determine  appropriate  system 
baselines  that  guarantee  the  presenee  of  the  fiinetional  capabilities  neeessary  to 
suceessfully  eonduct  the  MOC  mission.  These  issues  are  eovered  more  in  depth  in 
Section  3. 


1.3  BACKGROUND 

1.3.1  MHQ  with  MOC  Concept 

The  MHQ  with  MOC  eoneept  was  envisioned  to  standardize  the  processes  and 
proeedures  in  whieh  a  Navy  Combatant  Commander  assesses,  plans,  and  executes 
activities  at  the  operational  level  (U.S.  Fleet  Forees  Command,  2007).  Vice  Admiral 
M.G.  Williams,  Jr.,  former  Deputy  Commander  U.S.  Fleet  Forees  Command,  stated  the 
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overall  purpose  of  implementing  the  MOC  concept  is  “to  provide  common  processes  and 
methods  to  allow  different  Maritime  Headquarters  to  evolve  towards  standardization  of 
assessment,  planning  and  execution  at  the  operational  level  of  war.”  (U.S.  Fleet  Forces 
Command,  2007).  It  enables  the  Combatant  Commander  to  effectively  fight  the  Global 
War  on  Terror  (GWOT)  and  manage  Naval  assets  while  remaining  flexible  enough  to 
adapt  as  necessary  to  crisis  situations  as  they  arise.  Each  MHQ  would  be  part  of  a  global 
network  enabling  high-speed  net-centric  communications,  collaboration,  and  data 
sharing.  Standardization  of  MHQ  processes  and  procedures  would  allow  for  coordinated 
training  of  MHQ  staff  and  a  baseline  standard  set  of  component  systems  used  in  the 
MOC.  MOCs  would  have  the  ability  to  scale  operational  activities  to  respond  to  crisis  as 
they  arise  and  return  to  normal  operations  when  they  are  resolved. 


Figure  1  depicts  the  staffing  of  the  MHQ,  which  handles  both  Fleet  Management 
activities  and  Operational-Level  activities,  both  of  which  are  aided  by  a  shared  support 
staff  with  specialized  skills  that  can  be  tailored  given  the  Combatant  Commander’s 
(CCDR’s)  operational  environment. 
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Figure  1  -  MHQ  Staffing  and  Roles 

This  diagram  highlights  the  dual  role  of  the  MHQ  with  responsibilities  in  the  Fleet 
management  and  Operations.  (Department  of  the  Navy  Chief  Information  Officer) 
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The  MOC  component  of  the  MHQ  was  envisioned  as  a  system-of-systems,  (SoS)  both 
physical  component  systems  and  staff  personnel,  who  would  be  assigned  to  various  cells, 
bureaus,  or  working  groups,  coordinating  as  needed  to  perform  the  various  activities  of 
MOC  operations.  The  MOC  would  act  as  a  process-driven  entity  following  the  paradigm 
of  Assess,  Plan,  and  Execute  (U.S.  Fleet  Forces  Command,  2007).  This  paradigm, 
although  not  aligned  exactly  with  the  Navy’s  Command  and  Control  doctrine,  does  fulfill 
the  intent  (Naval  Doctrine  Publication  6  (NDP  6),  1995).  In  this  way,  a  MOC  would 
continually  assess  the  overall  naval  environment  within  the  area  of  responsibility  (AOR) 
as  it  pertained  to  operational  objectives.  Based  on  those  assessments,  the  MOC  would 
plan  activities  to  meet  operational  objectives  and  monitor  their  execution  by  subordinate 
tactical  forces,  then  assess  the  effects  of  those  operations. 


1.3.2  MOC  Core  Processes 

In  order  for  the  MOC  to  perform  the  necessary  functions  for  operational-level  operations, 
a  set  of  standardized  core  processes  was  developed  following  the  guidelines  of  Joint 
Capabilities  Alignment  (JCA)  and  derived  from  the  UJTLs  (Joint  Staff,  2008).  These 
core  processes  form  the  bulk  of  operations  to  be  performed  by  the  MOC  and,  as  listed 
below,  form  a  baseline  that  can  be  scaled  if  the  situation  warrants.  They  were  developed 
further  within  the  architecture  products  that  included  Operational  Views  (OV),  System 
Views  (SV),  and  Activity  Views  (AV).  The  OV-6c  relates  the  tasks  and  activities 
necessary  to  accomplish  the  process  flow. 


The  MOC  Core  Processes  used  in  this  analysis  were  taken  from  the  OV-6c 
documentation  and  are  provided  in  Table  1  with  a  brief  description. 
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Table  1  -  Core  Processes  Descriptions 


Core  Process 

Description 

Assess  Effects 

A  continuous  assessment  of  the  effect  of  current  missions  and 
operations  conducted  by  the  MOC,  going  beyond  initial  success 
or  failure  indications  to  assess  whether  follow-on  action  is 
necessary  and  how  changing  environment  and  battlespace 
affects  the  operating  scenario. 

Operational  Intelligence 

Determine  what  critical  intelligence  information  is  needed  to 
complete  operational  objectives,  bringing  to  bear  ah  intelligence 
gathering  assets  at  the  MOCs  disposal. 

Operational  Planning 

Operational  Planning  is  used  to  ensure  that  employment  of 
forces  is  mapped  to  operational  and  mission  objectives.  Allows 
for  coordination  of  Naval  operations  in  joint  force  activities. 

Manage  Information 

Ensure  that  the  command  has  the  information  necessary  to 
complete  operational  and  mission  objectives  will 
managing/minimizing  information  overload. 

Establish  HQ 

Perform  all  necessary  tasks  to  setup  a  MHQ  command  structure, 
establish  decision  authority  and  delegate  mission  planning  and 
execution  organizational  authority 

Execute  Plans 

Oversees  and  monitors  the  execution  of  plans,  assess  their 
performance  and  adapt  as  necessary. 

1.3.3  Approach 

The  methodology  ehosen  to  guide  our  efforts  eonsists  of  a  five-phase  approaeh 
ineorporating  the  systems  engineering  principles  discussed  earlier.  Efforts  were 
organized  into  research,  requirements,  relationships,  analysis  and  conclusion.  Each  phase 
accomplished  a  specific  purpose  that  supported  each  subsequent  phase.  Even  though 
timelines  were  established  for  each  phase,  this  only  changed  the  focus  of  efforts  by  team 
members.  Continued  work  on  previous  phases  did  not  stop  entirely.  For  instance, 
research  continued  throughout  the  entire  life  of  the  project,  but  the  bulk  of  the  effort  was 
accomplished  early  on.  Details  of  each  phase  are  addressed  in  Sections  2  and  3. 
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2  RESEARCH  SUMMARY 


2.1  OVERVIEW 

The  first  objective  was  to  gain  an  understanding  of  the  Maritime  Headquarters  with 
Maritime  Operations  Center  (MHQ/MOC).  The  key  questions  to  answer  were  1)  what  is 
a  MOC,  2)  what  is  the  purpose  of  the  MOC  and  3)  what  are  the  operations  and  functions 
of  the  MOC.  To  answer  these  questions  the  team  started  basic  information  gathering. 
Team  members  began  searching  the  internet,  using  Google,  Yahoo,  and  other  search 
engines  for  both  commercial  and  military  references.  The  online  Dudley  Knox  Library  at 
the  Naval  Postgraduate  School  was  utilized,  including  database  searches  and  librarian 
assistance. 

Team  members  began  working  with  the  MOC  Working  Group,  mostly  involved  with  the 
MOC  Architecture  Integrated  Product  Team  (IPT),  reviewing  documents  and 
interviewing  its  members.  The  team  met  with  the  sponsor,  LCDR  Bill  Brown,  Deputy 
for  the  Space  and  Naval  Warfare  Systems  Command  (SPAWAR)  Model  &  Simulation 
department,  for  his  input  on  the  history  and  current  direction  of  the  MOC.  Over  the 
course  of  the  project,  team  members  also  met  with  several  Subject  Matter  Experts 
(SMEs)  from  SPAWAR  to  include  the  Technical  Director,  Dr.  Bill  Rix;  Chief  Systems 
Engineer  for  Networks,  Raymond  Buchholz;  and  Chief  Systems  Engineer  for  Large 
Decks,  Michael  Davis.  The  team  also  met  with  our  advisor  John  “Mike”  Green  on 
several  occasions  to  gain  insight  on  the  MOC  and  to  structure  and  focus  the  effort  of  this 
project. 

Once  the  team  had  answers  to  the  key  questions,  the  research  focused  on  gaining 
knowledge  of  the  requirements  driving  the  MOC  concept.  These  driving  requirements  in 
turn  lead  to  the  establishment  of  a  process  and  methodology  for  determining  the 
capabilities,  or  lack  of  capabilities,  defined  in  current  MOC  documents. 
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2.2  SCOPE  AND  DEPTH 


Numerous  documents  and  articles  were  collected  and  reviewed  to  gain  insight  and 
knowledge  on  the  MHQ/MOC.  The  bibliography  section  of  this  document  lists  the 
documents  reviewed  for  the  development  of  this  report.  The  documentation  collected 
ranged  from  presentations,  articles,  requirement  documents,  and  minutes.  Among  the 
references  collected,  the  following  documents  were  extremely  useful  in  providing  the 
overall  requirements:  UJTLs,  architectural  views  (SV-4a,  SV-5a,  SV-8,  OV-6c), 
MHQ/MOC  Concept  of  Operations  (CONOPS),  and  the  MOC  System  Descriptions 
document  generated  by  PMW-790  and  provided  by  Raymond  Buchholz,  the  SPAWAR 
Chief  Systems  Engineer  for  Networks. 

This  research  led  the  team  to  review  the  CORE®  Architecture  Definition  Guide  (DoDAF 
vl.5)  documentation.  The  team  decided  to  use  CORE®  5.1.5  due  to  its  capability  of 
developing  operational  architectures  based  on  the  MOC  CONOPS.  The  operational 
architecture  for  MOC  also  required  the  team  to  enter  the  system  and  process  requirements 
into  the  CORE®  application.  CORE®  is  capable  of  producing  architectural  views  of  the 
MOC,  allowing  an  analysis  of  the  capabilities  and  functions.  The  team  utilized  the 
graphical  views  generated  in  CORE®  to  identify  gaps  in  the  capabilities  of  the  MOC  as 
provided  by  the  systems  included  in  the  implementation  of  the  MOC  concept. 


2.2.1  Research  Phase 

The  goals  of  the  research  included  gaining  familiarity  of  the  MOC  concept,  the  history  of 
events  leading  to  the  formal  initiation  of  efforts  in  the  development  of  the  MOC  concept, 
the  requirements  driving  the  development  of  the  MOC  concept,  the  level  of  effort 
expended  to  date  on  development,  and  the  current  state  of  execution.  The  focus  was  on 
the  military  sources,  but  included  research  on  commercial  influences.  Sources  included, 
but  were  not  limited  to,  interviews  of  stakeholders  and  subject  matter  experts,  personal 
involvement  in  IPTs,  the  use  of  the  World  Wide  Web,  program  office  document 
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repositories,  and  the  Naval  Postgraduate  School  online  library  and  journal  search 
capabilities. 

Early  research  exposed  the  team  to  various  IPX  artifacts  including  architecture  products. 
The  most  relevant  of  these  architectures  were  the  System  Views  and  Operational  Views 
provided  by  the  Architecture  IPX.  These  artifacts  quickly  became  the  foundation  of  our 
research,  allowing  us  to  scope  our  efforts  into  a  manageable  undertaking.  The  views 
most  influential  in  our  research  included  the  SV-4a,  SV-5a,  SV-8  and  OV-6c.  The  draft 
nature  of  each  artifact  limited  their  value,  but  highlighted  the  fact  that  development  of  the 
MOC  concept  is  being  driven  forward  without  solidified  requirements  and  with 
inadequate  architecture  descriptions.  The  lack  of  a  formal  requirements  document  was 
confirmed  in  a  discussion  with  the  Navy’s  Chief  Systems  Engineer  (CSE)  for  Large 
Decks  (Davis,  2009).  CSEs  are  responsible  for  conducting  Technical  Authority  reviews, 
representing  the  SPAWAR  Chief  Engineer. 

G.  Derrick  Hinton,  Chairman  of  the  International  Test  and  Evaluation  Association,  stated 
the  importance  of  architectures  in  the  systems  engineering  process  and  for  expanding 
beyond  point  solutions  “by  creating  an  architecture  as  the  central  aspect  of  the 
requirements  and  design  process.”  He  further  stated  the  role  of  architecture  as  the 
“bridge  from  requirements  to  design,  in  which  the  most  important,  critical  or  abstract 
requirements  are  used  to  determine  a  basic  segmentation  of  the  system.”  (Hinton,  2006) 

Without  validated  requirements,  a  relevant  architecture  cannot  be  developed.  The  desired 
end  state  cannot  be  accurately  expressed  without  the  relevant  architectures.  The 
architectures  are  the  “blueprint”  for  moving  beyond  a  concept.  Just  as  a  house  can  be 
built  without  blueprints,  so  can  a  system,  but  what  is  the  reliability  of  the  outcome?  To 
further  complicate  the  situation,  the  MOC  concept  requires  implementation  of  a  System 
of  Systems.  Although  numerous  definitions  of  a  SoS  exist,  the  following  is  most  closely 
applicable  to  the  MOC  concept: 
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In  relation  to  joint  warfighting,  system  of  systems  is  concerned  with 
interoperability  and  synergism  of  Command,  Control,  Computers, 
Communications,  and  Information  (C4I)  and  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR)  Systems.  Primary  focus:  Information  superiority. 
Application:  Military.  (Manthorpe,  1996) 

The  complexity  of  SoS  relationships,  accommodating  interoperability  and  system 
interfaces,  cannot  be  accurately  described  without  architectures.  The  relationship 
between  elements  and  interfaces  is  not  a  one-to-one  relationship.  On  the  contrary,  there 
is  an  exponential  increase  in  interfaces  as  elements  are  added  to  the  equation.  Citing 
Metcalfe’s  Law,  while  ignoring  disputes  on  its  continued  validity  (Briscoe,  Odlyzko,  & 
Tilly,  2006),  the  number  of  connections  a  component  can  make  with  other  components  in 
a  network  equals: 


n{n-l)  (1) 

or  roughly  nf  as  n  increases,  with  n  being  the  number  of  nodes  on  the  network.  Because 
the  systems  being  proposed  for  inclusion  into  the  MOC  are  not  all  interfaced,  the  system- 
to-system  and  human-to-system  interfaces  are  even  more  complex  if  not  ambiguous. 
Therefore,  every  time  a  new  system  (node)  is  proposed  for  inclusion  into  the  MOC  SoS, 
the  effects  cannot  be  clearly  recognized. 
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3  METHODOLOGY:  SUBSEQUENT  STEPS 


3.1  REQUIREMENTS 

Once  team  members  had  an  understanding  of  the  work  that  had  been  conducted  on  the 
MOC  and  the  supporting  artifacts,  the  focus  changed  to  understanding  the  requirements 
that  were  driving  the  work.  In  order  for  the  work  to  be  seen  as  relevant,  it  must  support 
traceability  to  the  source  requirements;  therefore  we  acknowledged  the  need  to  first 
identify  those  source  requirements.  Research  of  program  document  repositories  and 
discussions  with  key  personnel  has  supported  the  absence  of  any  validated  requirements. 

Without  formal  validated  requirements,  the  decision  was  made  to  trace  the  tasks  provided 
in  the  OV-6c  to  the  original  source  documents.  The  MOC  CONOPS  describes  core 
processes  that  support  “standardized  processes  and  methods  that  are  fully  compatible 
with  both  service  and  joint  guidance”  with  the  goal  of  facilitating  the  sharing  of 
information,  coordination,  and  load  sharing  between  MOCs  when  necessary  (U.S.  Fleet 
Forces  Command,  2007).  It  specifically  cites  an  analysis  of  the  UJTLs  as  the  foundation 
of  the  MOC  core  processes.  This  document  also  credited  the  operational  architecture  as 
the  source  used  to  compile  the  descriptions  of  the  core  processes  to  include  “inputs, 
major  players,  and  products.”  Involvement  with  the  MOC  Architecture  IPT  made  it  clear 
that  the  architectures  were  still  evolving,  yet  these  artifacts  were  the  foundation  for  the 
development  of  the  processes  that  define  the  MOC.  Review  of  the  architectures 
published  to  the  Department  of  Defense  Architectural  Repository  System  (DARS) 
revealed  numerous  references  to  draft  documents  as  resources  in  their  development.  One 
specific  example  in  the  OV-5  Activity  Model,  the  operational  task  of  Prepare  Plans  and 
Orders  (OP  5.3)  cites  the  draft  version  of  the  Capabilities  Development  Document  (CDD) 
for  the  Net-Enabled  Command  Capability.  Further  research  is  necessary  to  determine  if 
there  has  been  sufficient  configuration  management  implemented  to  account  for  changes 
to  referenced  capabilities  and  the  effect  those  changes  may  have  had  on  the  processes  and 
systems  developed  around  the  originally  proposed  capability. 
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The  absence  of  validated  requirements  and  architectural  views  brought  to  question  the 
inherent  limitations  in  the  accuracy  of  the  initial  analysis  conducted  in  order  to  establish 
the  core  processes.  It  was  recognized  that  numerous  assumptions  of  validity  were 
necessary  in  order  to  move  forward.  Although  the  UJTLs  were  accepted  as  the 
authoritative  documents  for  the  operational  activities  of  war,  the  knowledge  and 
experience  of  those  persons  who  conducted  the  analysis  of  the  UJTLs  to  develop  the  core 
processes  is  unknown.  Every  element  of  warfare  has  been  addressed  in  the  CONOPS  and 
other  artifacts,  and  an  underlying  assumption  has  been  made  that  the  resultant  products 
are  valid. 


3.2  RELATIONSHIPS 

The  following  paragraphs  describe  the  team’s  efforts  to  identify  relationships  between 
MOC  tasks  and  systems.  This  began  with  a  review  of  the  published  architecture  views  in 
DARS.  Systems  Architect  (viewer)  is  the  software  tool  used  to  examine  the  architecture 
products  maintained  in  DARS.  In  addition  to  viewing  the  products,  the  system  also 
provided  background  information  on  each  of  the  elements,  such  as  which  documents 
were  used  referenced  during  the  generation  of  the  view. 

If  the  published  architectures  are  considered  to  be  valid,  the  existing  depiction  of  required 
actions  in  the  OV-6c  can  be  used  to  establish  the  relationships  between  activities  and 
systems  and  generate  a  valid  Operational  Activity  to  Systems  Function  Traceability 
Matrix  (SV-5a).  The  draft  SV-5a  developed  by  the  MOC  working  group  currently  exists 
in  an  Excel  spreadsheet  in  the  form  of  a  matrix  with  1,067  rows  and  517  columns,  which 
are  split  between  three  different  worksheets.  This  matrix  consists  of  551,639  cells  that 
are  meant  to  identify  relevant  information,  and  the  data  it  contains  is  entered  and  tracked 
manually. 

The  limited  usefulness  of  the  draft  SV-5a  can  also  be  attributed  to  the  lack  of  validated 
requirements.  At  the  time  of  review,  the  1,067  rows  in  the  matrix  listed  the  required 

system  functions  proposed  by  the  working  group,  most  of  which  had  not  been  derived 
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from  the  MOC  processes.  On  the  contrary,  the  list  of  functions  appeared  to  have  been 
developed  independently  of  the  core  processes  and  was  drawn  from  sources  such  as  the 
Common  Systems  Function  List  (CSFL)  and  FORCEnet  System  Functions  (FnSF). 
Some  “new”  system  function  requirements  have  been  included  by  unidentified  persons, 
but  as  they  were  included,  they  were  not  traced  to  governing  documentation.  In  May  of 
2009  the  Architecture  IPT  augmented  the  efforts  to  identify  relationships  to  the  core 
processes. 


3.2.1  Conceptual  vs.  Reality 

Development  of  the  MOC  concept  into  reality  has  posed  many  challenges.  One  such 
challenge  is  the  goal  to  provide  the  capabilities  desired  by  the  customer  as  quickly  as 
possible.  As  development  of  the  MOC  concept  progressed,  the  need  to  incorporate 
greater  capabilities  resulted  in  decisions  to  include  conceptual  systems  that  had  not  been 
fielded  (and  possibly  never  would  be)  into  the  design.  And  though  this  is  not  an 
uncommon  practice  in  acquisition,  the  risk  associated  with  doing  so  must  be 
acknowledged.  This  approach  has  been  seen  frequently  in  the  attempt  to  present  the 
MOC  concept  as  an  achieved  reality.  Documents  depicting  Spiral  builds  with  changing 
baselines  have  been  signed  and  released,  but  with  the  inclusion  of  “drawing-board” 
systems  and  placeholders  that  describe  future  capabilities  instead  of  achieved  technology. 


3.2.2  Interoperability  vs.  Integration 

During  the  relationship  phase,  the  discussion  of  multiple  systems  involved  in  single  core 
processes  inspired  numerous  discussions  on  requirements  for  information  sharing  or 
transfer  between  systems  to  accomplish  a  given  task.  Although  the  issue  was  determined 
to  exceed  the  scope  of  our  analysis,  the  fact  remained  that  these  relationships  would  have 
to  be  defined.  Normally  accomplished  in  a  program’s  Information  Support  Plan  (ISP), 
these  relationships  would  be  clearly  delineated  and  each  interface  would  require 
interoperability  testing  as  appropriate.  Research  into  the  MOC  effort  revealed  no  such 
document.  Our  analysis  acknowledged  the  inclusion  of  multiple  systems  in  various  core 
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processes  and  defaulted  to  the  assumption  that  appropriate  interoperability  or  system 
interfaees  existed,  whether  man-to-maehine  or  maehine-to-machine.  Further  analysis 
will  be  required  to  determine  the  extent  of  interoperability  required  in  the  MOC  construet 
as  well  as  data  format  as  it  affeets  the  exehange  of  information. 


3.2.3  Tracing 

The  aetual  process  of  traeing  relationships  of  tasks  to  systems  was  divided  among  team 
members  and  the  results  were  entered  into  the  software  tool  ehosen  to  assist  in  the 
analysis.  CORE®  5.1.5  was  chosen  by  the  team  to  provide  automation  in  the  tracing 
process.  The  availability  of  CORE®  through  the  NFS  Virtual  SE  Lab  allowed  access  by 
all  members.  An  assessment  of  the  eapabilities  of  the  tool  determined  it  would  provide 
the  necessary  functionality  to  accomplish  our  goal.  An  Analysis  of  Alternatives 
identified  it  as  the  most  appropriate  solution  to  our  automation  needs  based  on 
availability,  cost  and  performance. 

Initial  efforts  attempted  to  traee  systems  to  tasks  beginning  with  the  individual  tasks 
drawn  from  the  OV-6e.  It  quickly  became  apparent  that  redundant  efforts  were  oceurring 
because  different  members  of  the  team  were  tracing  the  same  eore  proeesses  owing  to  the 
existenee  of  a  one-to-many  relationship  between  eore  process  and  joint  tasks.  The  team 
revised  the  approaeh  by  distributing  the  domains  that  were  composed  of  the  different  core 
proeesses:  Assess  Effects;  Operational  Intel;  Operational  Planning;  Manage 

Information;  Establish  Headquarters;  and  Execute  Plans.  This  ensured  no  redundant 
activities  were  assigned  while  distributing  the  workload  nearly  evenly. 

To  assist  in  the  traeing,  an  Exeel  spreadsheet  was  ereated  that  consolidated  the  parent  and 
ehild  activities  into  a  useable  format  for  each  of  the  core  processes  (Figure  2).  This 
eliminated  the  need  for  eaeh  member  to  search  through  numerous  pages  of  flow  diagrams 
in  the  body  of  the  OV-6e.  Information  was  first  entered  into  the  spreadsheet  to  facilitate 
a  quick  transcription  into  CORE®,  thus  limiting  the  time  spent  operating  in  the  Virtual 

Systems  Engineering  Lab.  Individual  tabs  in  the  spreadsheet  corresponded  to  each 
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mission  area  domain.  Each  core  process  was  then  broken  down  into  parent  and  child 
activities  corresponding  with  those  in  the  OV-6c.  Columns  were  provided  to  identify  the 
system  allocated  to  accomplish  the  task  and  the  spiral  build  the  system  was  assigned  to  if 
applicable. 
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Figure  2  -  CORE®  preparation 

A  spreadsheet  derived  from  the  elements  of  the  OV-6c  was  developed  to  streamline 
the  capture  of  information  and  minimize  the  time  spent  transcribing  date  into 
CORE®  while  logged  into  the  Virtual  Systems  Engineering  Lab  on  the  NFS 
network. 


3.2.4  CORE®  Schema 


The  resulting  spreadsheets  were  transcribed  into  the  CORE®  5.1.5  tool  on  the  NFS 
Virtual  Systems  Engineering  Lab.  As  seen  in  Figure  3,  the  Systems  Engineering  schema 
was  selected,  although  the  DoDAF  schema  was  considered  as  an  alternative.  Further 
consideration  for  appropriate  schema  selection,  or  creation,  is  recommended  for  future 
efforts  using  the  tool,  but  the  schema  selected  was  determined  to  be  more  appropriate  for 
this  project. 
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Figure  3  -  SE  Schema 

This  screenshot  of  the  SE  Schema  within  CORE®  shows  which  elements  were  used 
to  conduct  the  analysis. 

Elements  in  the  Systems  Engineering  Schema  that  were  utilized  in  the  relationship 
tracing  included  Component;  Document;  Function;  Issue;  and  Requirement.  The  first 
step  in  setting  up  the  schema  was  to  determine  what  information  was  necessary  to  create 
the  elements  within  the  CORE®  project. 


3.2.5  CORE®:  Requirement 

The  MHQ  MOC  CONOPS  provided  the  information  necessary  to  derive  requirements. 
The  mission  area  descriptions  in  the  CONOPS  identified  the  responsibilities  of  each 
element  and  sub-element  within  the  MOC  organization.  These  were  drawn  out  as 
individual  requirements  to  which  the  functional  requirements  could  be  associated  and 
were  entered  into  CORE®  as  “Requirement.”  As  they  were  entered,  a  relationship  of 
“documented  by”  was  established  with  the  CONOPS  in  order  to  validate  the  requirement. 
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3.2.6  CORE®:  Function 


The  OV-6c  provided  to  the  team  identified  the  necessary  functions.  Each  process  flow 
identified  consisted  of  a  string  of  parent  and  child  activities.  Each  of  these  activities  had 
to  be  accomplished  in  order  for  the  core  process  to  be  completed,  and  it  was  the 
completion  of  these  core  processes  that  provided  the  capabilities  necessary  to  accomplish 
the  identified  mission.  These  activities  were  designated  as  “Function”  in  CORE®  and 
became  the  target  of  the  functional  tracing  that  would  determine  if  capability  gaps 
existed.  As  they  were  entered,  a  relationship  of  “decomposed  by”  was  assigned  to  child 
activities  in  relation  to  the  parent  activity  from  which  they  were  derived.  This  established 
the  hierarchal  relationship  to  be  used  for  the  gap  analysis.  If  a  child  activity  could  not  be 
completed,  the  parent  activity  also  could  not  be  completed.  This  allowed  for  an  in-depth 
analysis  that  would  not  be  apparent  otherwise. 


3.2.7  CORE®:  Component 

The  ultimate  goal  of  this  project  was  to  assign  systems  to  functions  in  order  to  determine 
if  the  MOC  could  accomplish  the  missions  assigned  to  it  using  those  systems.  The  entire 
effort  hinged  on  the  ability  to  identify  and  assign  those  relationships.  One  barrier  that 
was  presented  was  the  ability  to  identify  systems  that  would  become  standardized  in  their 
use  by  the  various  fleet  customers.  Without  that  standardization,  each  MOC  could  utilize 
their  solution  and  one  basic  goal  of  the  MOC  concept  would  remain  unrealized.  During 
the  research  of  documentation,  two  letters  signed  out  by  the  Director,  Warfare  Integration 
(N6F)  only  one  year  apart  were  discovered  that  were  meant  to  accomplish  that 
standardization.  The  first,  with  the  subject  “MARITIME  HEADQUARTERS  WITH 
MARITIME  OPERATIONS  CENTER  (MHQ  w/MOC)  SYSTEMS  REQUIREMENTS” 
provided  an  enclosure  listing  the  systems  that  were  to  comprise  the  spiral  8  baseline 
(Director,  Warfare  Integration  N6F,  2007).  The  second,  with  the  same  subject,  was  to  be 
the  update  with  the  spiral  10  baseline  (Director,  Warfare  Integration  N6F,  2008).  The 
expectation  that  the  spiral  10  baseline  would  include  the  systems  from  the  spiral  8 
document  was  not  realized.  The  spiral  10  document  only  referenced  the  previous  release 
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and  showed  only  the  newly  identified  MOC  systems.  Although  the  information  did  exist, 
the  ability  to  obtain  the  offieial  documentation  was  less  than  efficient.  These  highlighted 
the  need  to  baseline  system  composition  in  a  single  location  or,  at  a  minimum,  provide 
additional  enclosures  to  subsequent  baseline  updates  that  show  all  of  the  systems  to  be 
included. 


3.3  ANALYSIS 

Upon  the  conclusion  of  establishing  the  relationships  between  the  activities  that 
comprised  the  core  processes,  an  analysis  of  the  tracing  efforts  began.  The  benefit  of 
entering  the  data  into  an  automation  tool  was  the  ability  to  manipulate  views  based  on  the 
level  of  detail  desired.  The  overall  view  helped  to  establish  a  perspective  of  the 
undertaking  at  hand.  There  were  496  functional  activities  included  in  our  analysis. 
These  activities  encompassed  the  derived  actions  necessary  to  accomplish  only  44  tasks. 
With  an  undetermined  number  of  tasks  that  would  comprise  the  entire  portfolio  of 
mission  requirements,  the  complexity  of  a  complete  analysis  can  be  inferred.  That 
knowledge  should  be  considered  when  considering  the  method  by  which  requirements 
will  be  continually  assessed  as  the  MOC  concept  evolves  and  additional  systems  are 
considered  for  inclusion. 

Automation  could  contribute  to  a  true  conditional  consequence  analysis  as  the  complexity 
of  the  relationships  increases  according  to  aforementioned  Metcalfe’s  Law.  As  the 
configuration  of  the  MOC  continues  to  evolve,  obsolete  systems  will  be  considered  for 
replacement  or  new  capabilities  will  be  achieved  with  additional  systems.  The  interfaces 
identified  for  each  system  would  allow  a  rapid  assessment  of  the  consequences  for 
removing  a  system,  which  activities  are  affected  by  that  removal,  and  whether  those 
capabilities  can  be  achieved  by  the  replacement  system  or  through  some  other  interface. 
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3.4  ARRIVING  AT  CONCLUSIONS 


The  final  phase  of  the  team’s  project  was  the  formulation  of  a  conclusion  to  the  question 
of  whether  a  MOC  can  complete  the  missions  assigned  based  on  functional  capabilities 
present  in  the  configuration  of  systems.  The  analysis  did  show  the  existence  of  capability 
gaps;  therefore  the  MOC  will  be  unable  to  perform  the  missions  assigned  with  organic 
systems  unless  capability  augmentation  is  conducted.  This  conclusion  will  be  explained 
in  greater  detail  in  Sections  4  and  5. 
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4  METHODOLOGY  APPLICATION  AND  VALIDATION 


This  section  summarizes  efforts  executed  in  support  of  the  MOC  traceability  project 
described  in  Section  3.  It  further  documents  and  examines  the  capability  gaps  in 
implementing  MOC.  The  following  sub-sections  provide  detailed  findings  of  the  analysis. 

As  detailed  in  Section  3,  well-documented  systems  engineering  (SE)  processes  were  not 
used  in  earlier  studies  generating  MOC  requirements.  Lack  of  SE  process  is  evident  in 
the  DoDAF  artifact,  OV-6c,  as  it  struggled  to  decompose  the  high  level  MOC 
requirements  into  business  rules  and  tactical  functions.  The  following  sub-sections 
describe  the  gaps  discovered  when  trying  to  allocate  the  requirements  to  systems. 


4.1  EXECUTION  OF  OVERALL  APPROACH 

The  MOC  requirements  were  obtained  from  the  CONOPS,  the  OV-6c,  and  several  high 
level  directives.  Our  Capstone  team  applied  several  methods  in  conducting  the  functional 
analysis.  Initially,  the  team  identified  a  small  pool  of  systems  that  could  fulfill  the  six 
top-level  MOC  functional  areas.  This  initial  analysis  was  conducted  utilizing  a  Microsoft 
Excel  spreadsheet  and  was  conducted  before  specific  systems  planned  for  the  MOC  were 
known  to  the  team.  Once  the  Spiral  8  and  Spiral  10  systems  were  identified,  the  Capstone 
team  repeated  a  similar  Microsoft  Excel  analysis.  The  final  gap  analysis  was  conducted  in 
CORE®. 

4.1.1  Section  Overview 

Requirements  were  allocated  to  systems  using  CORE®,  a  systems  engineering  tool  used 
to  document,  decompose  and  allocate  requirements.  The  remainder  of  this  section 
discusses  the  steps  taken  to  populate  the  requirements  into  CORE®,  find  association  to 
other  requirements  (if  any),  allocate  them  to  systems,  and  identify  gaps  where  systems 
have  not  been  identified  to  satisfy  a  given  requirement. 
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As  described  in  Section  3,  because  the  number  of  functions  developed  by  the  MOC 
Architecture  IPX  was  so  high,  our  capstone  team  had  to  first  identify  the  ones  that  were 
traceable  to  requirements.  Instead  of  the  1,067  functions  listed  in  the  SV-5a,  the  team 
identified  and  uploaded  to  CORE®  496  tasks  extracted  from  the  OV-6c.  Similarly,  the 
known  requirements  documents,  reference  documents,  and  components  were  identified 
and  uploaded  into  CORE®. 

Next,  relationships  between  functions  were  identified  and  established  in  CORE®.  In  this 
process,  some  of  the  tasks  were  identified  to  be  children,  or  sub-functions,  of  other 
functions.  Identification  of  relationships  between  tasks  assisted  in  the  decomposition  of 
high-level  requirements  to  lower-level  requirements  that  could  then  be  allocated  to 
components. 

Allocation  to  systems  followed  next.  The  pool  of  systems  loaded  to  CORE®  was  derived 
from  Spirals  8  and  10  of  MOC  System  Description  documents.  Our  Capstone  team 
researched  each  system’s  capability  and  allocated  functions  to  appropriate  systems.  The 
following  sub-sections  will  describe  details  of  the  systems  allocation  process  and  results 
of  the  gap  analysis. 


4.2  REQUIREMENTS  GENERATION  AND  ANALYSIS 

Figure  4  graphically  depicts  the  six  core  processes  that  comprise  the  actions  which  fulfdl 
the  44  functions  identified  in  the  OV-6c  and  were  assessed  by  the  team.  The  following 
paragraphs  will  discuss  the  results  of  the  team’s  assessment. 
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Figure  4  -  MOC  Core  Processes 

This  figure  depicts  the  six  core  processes  performed  by  the  MOC  (U.S.  Fleet  Forces 
Command,  2007) 

4.2.1  Assess  Effects 

The  MOC  Architecture  IPX  obviously  had  a  difficult  task  of  defining  the  core  processes 
because  the  MOC  did  not  follow  the  normal  DoD  acquisition  process  or  a  disciplined 
systems  engineering  development  process.  Instead,  existing  U.S.  Naval  commands  were 
asked  to  describe  how  to  perform  MOC  activities.  As  such,  the  MOC  functions  enlisted 
by  the  MOC  Architecture  IPX  were  simply  lists  of  functions  each  command’s  capability 
needed  to  effectively  synchronize  joint  maritime  operations  in  planning,  execution  and 
assessment  of  operations.  This  unorthodox  requirement  generation  method  has  resulted  in 
several  requirement  overlaps  and  some  requirement  gaps. 

The  first  top-level  function  analyzed  was  Assess  Effects.  The  Capstone  team  identified 
sixteen  core  processes  to  address  the  Assess  Effects  function.  Each  of  these  tasks  was 
successfully  allocated  to  available  systems. 


4.2.2  Operational  Intelligence 

Using  similar  method  of  segregation  of  MOC  functions,  our  Capstone  team  identified 
102  activities  to  be  associated  with  Operational  Intelligence  (OPINXEL).  These 
requirements  were  identified  to  the  best  of  our  team’s  understanding  based  on  their 
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descriptions  and  estimates  of  their  capability  of  meeting  a  MOC  requirement.  All  102 
were  successfully  allocated  to  systems. 


4.2.3  Operational  Planning 

The  MOC  Operational  View  (OV-6c)  our  team  received  did  not  provide  complete 
information  on  what  needed  to  be  accomplished  and  who  should  be  doing  it. 
Requirements  for  Operational  Planning  were  relatively  easier  to  identify  as  MOC  is  an 
operation-centered  defense  component.  There  were  112  activities  identified  to  satisfy  the 
Operational  Planning  requirement.  One  hundred  eight  of  the  activities  were  successfully 
allocated  to  systems. 


4.2.4  Manage  Information 

Eighty-five  activities  were  identified  that  applied  to  the  5  sub-processes  that  made  up  the 
core  process  Manage  Information.  The  sub-processes  that  make  up  the  Manage 
Information  core  process  are  Manage  Requests  for  Operational  Information,  Develop  IM 
Plan,  Manage  Battle  Rhythm,  Establish  Collaborative  Information  Environment  (CIE), 
and  Conduct  CND  Operations.  Most  of  the  functions  within  Manage  Information  were 
successfully  allocated  to  systems.  Sixty-nine  of  the  activities  were  successfully  allocated 
to  systems. 


4.2.5  Establish  Headquarters 

Forty-four  activities  were  identified  for  the  core  process  of  Establish  Headquarters.  Of 
the  44  activities,  39  were  traced  to  systems.  The  Establish  Headquarters  core  process 
was  further  refined  to  Establish  HQ  and  Coordinate  Joint  Training  sub-processes.  Most 
of  the  functions  under  this  core  process  were  allocated  to  the  Global  Command  and 
Control  Systems-Maritime  (GCCS-M).  Descriptions  of  these  systems  are  detailed  in  most 
of  the  referenced  documents. 


24 


4.2.6  Execute  Plans 


Similarly,  135  functions  were  identified  to  be  associated  to  Execute  Plans  core  process. 
112  of  them  were  successfully  traced  to  systems.  Results  of  the  gap  analysis  on  the 
remainder  are  discussed  in  the  next  section. 


4.3  MOC  FUNCTIONAL  ANALYSIS  AND  ALLOCATION 

As  discussed  previously,  an  analysis  was  performed  by  the  MOC  project  team  to 
determine  whether  the  functions  required  by  the  MOC,  identified  in  the  OV-6c,  can  be 
fulfilled  by  current  and  proposed  systems.  The  MOC  Spiral  8  Systems  Description 
document,  MOC  Spiral  10  Systems  Description  document,  and  current  systems  not 
identified  in  the  MOC  systems  documents  were  considered  for  the  functional  allocation 
analysis. 


Using  CORE®  5.1.5,  the  relationship  of  system  to  function  was  quickly  established.  If 
there  was  no  system  allocated  to  a  function,  then  the  model  would  graphically  depict  a 
GAP  component  allocated  to  the  function.  This  indicates  that  there  is  no  system  available 
that  can  accomplish  the  function  and  a  capability  gap  exists.  Figure  5  provides  an 
example  of  a  CORE®  graphical  depiction  of  a  capability  gap.  The  following  section 
includes  excerpts  of  the  tables  provided  in  the  Appendix.  These  excerpts  depict  examples 
of  the  systems  assigned  to  each  of  the  core  process  activities  and  any  gaps  identified. 
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Figure  5  -  Capability  Gap  Depicted  in  CORE® 

This  figure  illustrates  a  capability  gap  with  reasoning  provided  as  an  Issue 

4.3.1  Assess  Effects 

As  seen  in  Table  8,  all  functions  within  the  Assess  Effects  core  process  were  allocated  to 
GCCS-M.  In  addition,  6  of  the  16  functions  were  also  allocated  to  Command  and 
Control  PC  (C2PC)  and  3  were  also  allocated  to  the  Air  Defense  System  Integrator 
(ADSI).  Overall,  3  functions.  Determine  MOEs  Achieved,  Determine  Success  or  Failure 
and  Determine  Unintended  Effects  were  allocated  to  all  3  systems,  GCCS-M,  C2PC  and 
ADSL  Assess  Battle  Effects,  Conduct  Weapons  Effectiveness  Assessment  and  Compare 
Achieved  vs.  Desired  Results  were  allocated  to  2  systems,  GCCS-M  and  C2PC.  All 
remaining  functions  were  allocated  only  to  GCCS-M.  Although  GCCS-M  is  able  to 
perform  all  required  functions  that  enable  a  MOC  to  continually  assess  the  outcome  of 
operations,  a  command  can  still  perform  functions  under  the  Assess  Effects  core  process 
with  C2PC  and/or  ADSL  This  indicates  possible  capability  overlaps.  It  could  also 
indicate  back-up  capabilities  to  accommodate  failure  or  heavy  loading  of  primary 
systems. 


Table  2  -  Excerpts  of  Table  8  Systems  Allocated  to  Assess  Effects  Functions 


Functions 

Systems 

AE.1.1 

Develop  Assessment  Plan 

GCCS-M 

AE.1.2 

Assess  Achievement  of  Desired  Effects 

GCCS-M 

AE.E2.1 

Develop  Combat  Assessment  Plan 

GCCS-M 

AE.E2.2 

Assess  Battle  Effects 

GCCS-M,  C2PC 

AE.E2.3 

Estimate  Initial  Damage 

GCCS-M 
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Table  2  (continued) 


Functions 

Systems 

AE.  1.2.4 

Estimate  Functional  Damage 

GCCS-M 

AE.1.2.5 

Estimate  Ability  to  Reconstitute 

GCCS-M 

AE.  1.2.6 

Conduct  Weapons  Effectiveness  Assessment 

GCCS-M,  C2PC 

AE.  1.2.7 

Develop  Process  for  Monitoring  &  Understanding 
Operational  Environment 

GCCS-M 

AE.  1.2.8 

Provide  Feedback  on  Operations 

GCCS-M 

4.3.2  Operational  Intelligence 

In  this  section,  all  available  systems  that  would  help  determine  the  critical  information  a 
commander  requires  to  understand  the  flow  of  operations  and  to  make  timely  and 
informed  decisions  were  identified.  Systems  identified  in  this  section  would  gather 
friendly,  enemy,  and  environmental  information.  A  total  of  102  tasks  were  identified  to 
support  this  core  MOC  process  and  all  were  allocated  to  one  or  more  systems.  Of  these 
processes,  58  were  successfully  allocated  to  the  Global  Command  and  Control  System- 
Integrated  Imagery  and  Intelligence  (GCCS-I3)  and  GCCS-M  systems.  Complimentarily, 
36  other  processes  were  allocated  to  the  systems  Generic  Area  Limitation  Environment 
(GALE),  Joint  Service  Imagery  Processing  System  (JSIPS),  Distributed  Common  Ground 
System-Navy  (DCGS-N)  and  Analyst  Notebook.  Three  activities  were  allocated  to  the 
Net-Centric  Enterprise  Services  Collaboration  Tool  (NCES)  and  Information  Work  Space 
(IWS),  and  5  were  allocated  to  Joint  Deployable  Intelligence  Support  System  (JDISS) 
and  DCGS-N.  A  more  detailed  accounting  of  the  systems  allocated  to  each  function  is 
listed  in  Table  9.  Functions  that  have  more  than  one  system  allocated  indicated  a 
possible  capability  overlap.  Details  of  the  gap  analysis  are  documented  in  the  next 
section. 


Table  3  -  Excerpts  of  Table  9  Systems  Allocated  to  Operational  Intelligence 
Functions 


Functions 

Systems 

01.1.1 

Review  Mission  for  OPINTEL  Needs 

GCCS-M,  GCCS-I3 

01.1.2 

Develop  PIRs 

GCCS-M,  GCCS-I3 

01.1.2.1 

Analyze  OPLAN,  COAs  and  ECOAs  by  Phases 

GCCS-M,  GCCS-I3 

01.1.2.2 

Collate  Intelligence  Required  for  Operational  I&W 

GCCS-M,  GCCS-I3 
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Table  3  (continued) 


Functions 

Systems 

01.1.2.3 

Distill  Intelligence  Requirements 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.2.4 

Rank,  Prioritize  Intelligence  Requirements 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.2.5 

Determine  Intelligence  Vital  to  Mission  by  Phase  of  Op 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.3 

Identify  Intelligence  Knowledge  Gaps 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.4 

Generate  RFls 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.5 

Develop  Draft  Collection  Plan 

GCCS-M,  GCCS-13 

4.3.3  Operational  Planning 

Our  team  allocated  Operational  Planning  tasks  to  systems  that  enable  a  commander  to 
effectively  plan  for  and  execute  operations,  ensure  that  the  employment  of  forces  is 
linked  to  objectives,  and  integrate  naval  operations  seamlessly  with  the  actions  of  a  joint 
force.  The  Operational  Planning  core  process  was  decomposed  to  112  activities,  108 
were  successfully  allocated  among  25  systems  as  identified  in  Table  10.  A  large  number 
of  these  tasks  were  to  be  accomplished  by  utilizing  Global  Combat  Support  System  - 
Combatant  Commander  (GCSS-CC/JTF)  and  Collaborative  Force  Analysis,  Sustainment, 
and  Transportation  (CFAST).  Figure  6  is  a  graphical  depiction  of  the  number  of  tasks 
assigned  to  each  of  the  systems  identified  for  use  in  the  execution  of  Operational 
Planning. 

The  functions  that  did  not  have  any  systems  allocated  are: 

•  Determine  Recommended  CCIRs 

•  Develop  Appropriate  Annexes,  Appendixes  &  Tabs 

•  Reconcile  Plans  and  Orders 

•  Back  Brief  &  Crosswalk  Orders 


From  the  analysis  conducted  by  the  MOC  project  team,  there  does  not  appear  to  be  a 
known  system  that  has  the  capability  to  fulfill  these  functions.  These  are  shown  as 
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Capability  Gap  in  the  table.  Functions  that  had  more  than  one  system  allocated  to  it 
indicated  a  possible  capability  overlap. 


Figure  6  -  Operational  Planning  Tasks  allocated  to  Systems 

This  figure  details  the  number  of  activities  within  the  core  process  assigned  to  each 
of  the  systems  determined  to  provide  the  needed  capability. 


Table  4  -  Excerpts  of  Table  10  Systems  Allocated  to  Operational  Planning  Functions 


Functions 

Systems 

OPP.1.3 

Approve/Modify  Mission  Statement 

JADOCS,  JCRE 

OPP.1.8 

Approve/Modify  COA 

JCRE,  ISP  AN 

OPP.1.11 

Approve  Plans/Orders 

JCRE 

OPP.1.1 

Conduct  Operational  Mission  Analysis 

MIPS,  DCGS 

OPP.1.1.1 

Analyze  Higher  Commander's  Mission 

MIPS,  DCGS 

OPP.1.1. 2 

Develop  Objectives 

MIPS,  DCGS 

OPP.  1.4.2 

Determine  Recommended  CCIRs 

Capability  Gap 

OPP.  1.10.3 

Develop  Appropriate  Annexes,  Appendixes  &  Tabs 

Capability  Gap 

OPP.  1.10.6 

Reconcile  Plans  and  Orders 

Capability  Gap 

OPP.1.10.7 

Back  Brief  &  Crosswalk  Orders 

Capability  Gap 

29 


4.3.4  Manage  Information 

According  to  the  MOC  OV-6c,  “Information  management,  possibly  by  artificial  as  well 
as  human  agents,  would  ensure  that  decision  makers  have  ready  access  to  the  information 
they  want  and  need  while  minimizing  the  risk  of  information  overload.”  To  this  end,  6 
sub-processes  were  identified  and  further  refined  into  85  tasks.  Our  team  successfully 
allocated  these  tasks  among  30  systems.  As  shown  in  Figure  7,  the  Consolidated  Afloat 
Networks  and  Enterprise  Services  (CANES)  accomplishes  10  of  these  tasks;  however,  it 
is  clear  that  diverse  information  gathering,  filtering  or  analysis  systems  would  have  to  be 
deployed  in  order  to  accomplish  all  required  tasks  under  Manage  Information. 


Figure  7  -  Number  of  Manage  Information  Activities  allocated  to  Systems 

This  figure  details  the  number  of  activities  within  the  core  process  assigned  to  each 
of  the  systems  determined  to  provide  the  needed  capability. 

The  Manage  Information  core  process  was  decomposed  to  84  activities  of  which  66  were 
allocated  to  one  or  more  systems.  The  system(s)  allocated  to  each  function  can  be  found 
in  Table  11. 
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The  functions  that  did  not  have  any  systems  allocated  are  listed  here  and  assigned 
“Capability  Gap”  in  the  systems  column  in  Table  1 1 : 

•  Ensure  Authorized  Entities  &  Information  Used 

•  Adapt  info  Sharing  to  Accommodate  Evolving  Needs 

•  Manage  Information  Management  Cell 

•  Manage  Workgroup  Managers  (embedded/shared) 

•  Manage  Electronic  File  Plan 

•  Manage  Suspense  Control 

•  Provide  Component  IM  Cell  Services 

•  Develop  Data/Information 

•  Determine  Information  Pedigree 

•  Maintain  Information  Pedigree 

•  Establish  Digital  Rules  of  Protocol 

•  Identify  Subscription 

•  Request  Subscription 

•  Evaluate  Subscribed  Data/Information 

•  Update  Subscription 

•  Formulate  Discovery  Search 

•  Coordinate  IMP 

•  Provide  Computer  Network  Defense  Services 

From  the  analysis  done  by  the  MOC  project  team,  there  does  not  appear  to  be  a  known 
system  that  has  the  capability  to  fulfill  these  functions.  These  are  shown  as  Capability 
Gap  in  the  table.  Functions  that  had  more  than  one  system  allocated  indicated  a  possible 
capability  overlap. 


Table  5  -  Excerpt  of  Table  11  Systems  Allocated  to  Manage  Information  Functions 


Functions 

Systems 

MLl.l 

Ensure  Authorized  Entities  &  Information  Used 

Capability  Gap 
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Table  5  (continued) 


Functions 

Systems 

MI.  1.2 

Adapt  info  Sharing  to  Accommodate  Evolving  Needs 

Capability  Gap 

MI.  1.3 

Manage  Information  Management  Cell 

Capability  Gap 

MI.  1.3.1 

Manage  Workgroup  Managers  (embedded/shared) 

Capability  Gap 

MI.1.3.2 

Provide  Overall  Info-Related  Admin  Support 

MSRT 

MI.1.3.3 

Manage  Electronic  File  Plan 

Capability  Gap 

MI.1.3.4 

Manage  Messaging  Services 

TBMCS,  DJC2 

MI.1.3.5 

Manage  Suspense  Control 

Capability  Gap 

MI.1.3.6 

Provide  Component  IM  Cell  Services 

Capability  Gap 

MI.  1.4 

Provide/Publish  Data/Information  to  Net-Centric 

Environment 

CNDE,  CANES 

4.3.5  Establish  Headquarters 

The  Establish  Headquarters  core  process  was  decomposed  to  44  activities,  43  of  which 
were  allocated  to  at  least  one  or  more  systems.  The  system(s)  allocated  to  each  function 
can  be  found  in  Table  12.  The  majority  of  the  activities  could  be  accomplished  by  the 
GCCS  systems.  Other  systems,  such  as  the  Global  Combat  Support  System  (GCSS)  and 
Deployable  Joint  Command  and  Control  (DJC2),  also  fulfilled  some  of  the  activities 
allocated  to  the  GCCS  systems. 

The  activity  that  did  not  have  any  systems  allocated  is: 

•  Sub  Component  Interagency 

It  was  determined  that  this  activity  would  not  be  performed  by  MHQ  w/MOC.  This  is 
shown  as  a  Capability  Gap  in  the  table.  Activities  that  had  more  than  one  system 
allocated  to  it  indicated  a  possible  capability  overlap. 


Table  6  -  Excerpts  of  Table  12  Systems  Allocated  to  Establish  Headquarters 
Functions 


Functions 

Systems 

EHQ.1.1 

Establish  Appropriate  Organizational  Relationships 

GCCS-M 

EHQ.1.6 

Connect  &  Interface  with  Non-DoD  Organizations 

GCCS-M 

EHQ.1.7 

Establish  Role-Based  Knowledge  Framework 

GCCS-M 

EHQ.1.8 

Form  Distributed  Teams/COIs/CofP 

GCCS-M,  GCSS 
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Table  6  (continued) 


Functions 

Systems 

EHQ.  1.8.1 

Access  Subject  Matter  Expert  &  Essential 

Information 

GCCS-M,  GCSS 

EHQ.  1.8.2 

Identify  COI/CofP 

GCCS-M 

EHQ.  1.8.3 

Establish  COI/CofP 

GCCS-M 

EHQ.  1.8.4 

Develop  COI/CofP  Charter 

GCCS-M 

EHQ.1.8.5 

Prioritize  Information  Sharing  Capabilities 

GCCS-M,  GCSS 

EHQ.1.11 

Sub  Component  Interagency 

Capability  Gap 

4.3.6  Execute  Plans 

The  Execute  Plans  core  process  was  decomposed  to  135  activities;  of  which  119  were 
allocated  to  one  or  more  systems.  The  system(s)  allocated  to  each  activity  can  be  found  in 
Table  13. 

The  activities  that  did  not  have  any  systems  allocated  are: 

•  Administratively  &  Clinically  Validate  Patient 

•  Provide  Patient  Attendants  &  Movement  Items 

•  Move  Patient 

•  Conduct  Patient  Evacuation 

•  Provide  Headquarters  Personnel  &  Infrastructure 

•  Provide  Augmentation 

•  Provide  for  Personnel  Services 

•  Process  JIP  TL/JIP  CL/Asset  Appointment 

•  Provide  Tailored  Space  Training 

•  Develop/Maintain  Logistics  Base  in  JOA 

•  Predict  Repair/Maintenance  Requirements 

•  Sense  Repair/Maintenance  Requirements 

•  Configure  Netted  Sensor  Grid 

•  Task  Sensor 

•  Conduct  Dynamic  Cross-Cuing  of  Sensor  Data 

•  Provide  Sensor  Tip-Ojf 
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From  the  analysis  done  by  the  MOC  projeet  team,  there  does  not  appear  to  be  a  known 
system  that  has  the  eapability  to  fnlfdl  these  funetions.  This  is  shown  as  Capability  Gap 
in  the  table.  Activities  that  had  more  than  one  system  allocated  to  it  indicated  a  possible 
capability  overlap. 


Table  7  -  Excerpts  of  Table  13  Systems  Allocated  to  Execute  Plans  Functions 


Functions 

Systems 

EP.3.6.1 

Administratively  &  Clinically  Validate  Patient 

Capability  Gap 

EP.3.6.6 

Provide  Patient  Attendants  &  Movement  Items 

Capability  Gap 

EP.3.6.7 

Move  Patient 

Capability  Gap 

EP.3.7 

Conduct  Patient  Evacuation 

Capability  Gap 

EP.5.4 

Provide  Headquarters  Personnel  &  Infrastructure 

Capability  Gap 

EP.5.4.3 

Provide  Augmentation 

Capability  Gap 

EP.5.7 

Provide  for  Personnel  Services 

Capability  Gap 

EP.6.15 

Process  JIP  TL/JIP  CL/Asset  Appointment 

Capability  Gap 

EP.7.5 

Provide  Tailored  Space  Training 

Capability  Gap 

EP.9.2 

Develop/Maintain  Logistics  Base  in  JOA 

Capability  Gap 

EP.9.8.1 

Predict  Repair/Maintenance  Requirements 

Capability  Gap 

EP.9.8.2 

Sense  Repair/Maintenance  Requirements 

Capability  Gap 

EP.10.2 

Configure  Netted  Sensor  Grid 

Capability  Gap 

EP.10.3 

Task  Sensor 

Capability  Gap 

EP.10.4.3 

Conduct  Dynamic  Cross-Cuing  of  Sensor  Data 

Capability  Gap 

EP.10.4.4 

Provide  Sensor  Tip-Off 

Capability  Gap 

4.4  VERIFICATION  AND  VALIDATION 

Once  all  the  relevant  data  (documents,  requirements,  functions,  systems,  etc.)  had  been 
compiled,  the  relationships  were  established  as  described  in  Section  4.3.  The  next  phase 
of  the  project  involved  populating  the  model  in  CORE®  5.1.5.  The  CORE®  software  uses 
a  model-based  systems  engineering  (MBSE)  approach  for  system  and  architecture 
development.  For  the  purpose  of  this  project,  the  CORE®  software  was  used  establish 
traceability  from  the  MOC  CONOPS  and  other  documents  to  the  functions  and  systems. 
The  ultimate  goal  was  to  generate  graphical  views  to  allow  the  users  to  easily  identify  the 
MOC  capability  gaps  and  possible  overlaps. 
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The  Systems  Engineering  (SE)  sehema  in  CORE®  was  used  to  build  the  model.  The  SE 
schema  provided  the  classes,  relationships,  and  attributes  necessary  to  establish  the 
traceability  for  the  MOC  project.  Figure  8  provides  an  overview  of  the  classes  and 
relationships  that  can  be  established.  Not  all  of  the  available  class  relationships  were 
included  in  the  figure  for  clarity.  Additional  classes  were  used  in  the  MOC  project, 
including  Issue,  Document,  and  Category. 


(3  Requirement 
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This  diagram  refiectsthe  heart  of  the  systems 
engineering  schema.  Additional  classes  and 
reiationships  exist  to  capture  issues,  risks,  test 
devaluation  materiai,  and  much  more. 
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Figure  8  -  Overview  of  Class  Relationships  Established  in  CORE® 

This  diagram  reflects  the  heart  of  the  systems  engineering  schema.  Additional 
classes  and  relationships  exist  to  capture  issues,  risks,  test  &  evaluation  material, 
and  much  more.  (Vitech  Corporation,  2005) 


4.4.1  Populating  CORE® 

The  MOC  CONOPS  and  DODAF  artifacts  (SV-4a,  SV-5a,  SV-8,  and  OV-6c)  were  the 
primary  sources  of  data  for  populating  the  CORE®  model.  Populating  the  model  was 
expedited  with  the  aid  of  the  Element  Extractor  feature  in  CORE®.  The  Element 
Extractor  allows  the  user  to  quickly  populate  the  CORE®  model  from  existing 
documents.  The  relevant  documents  were  first  loaded  to  the  Element  Extractor.  The  user 
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then  selected  text  from  the  document  and  chose  a  field  in  the  Element  Definition  window 
to  be  populated.  Attributes  not  available  in  the  documents  had  to  be  entered  manually. 
Figure  9  shows  the  Element  Extractor  being  used  to  extract  text  from  the  MOC  Spiral  10 
Systems  Description  document. 


Figure  9  -  CORE®  Element  Extractor 

Captures  relevant  information  from  references  to  associate  with  individual  elements 


Data  was  extracted  to  elements  of  different  classes.  As  shown  in  Figure  10,  only  7  of  the 
SE  schema  classes  were  used  for  the  MOC  project.  The  Category  class  contains  Assess, 
Plan,  and  Execute  elements  to  which  all  the  requirements  are  categorized.  The 
Component  class  contains  the  systems  elements.  The  Document  class  contains  the 
document  elements.  The  Function  class  contains  the  functions  the  MOC  is  required  to 
perform.  The  Issue  class  contains  the  issue  elements,  which  are  allocated  to  functions  if 
an  issue  requiring  future  action  is  identified.  The  Item  class  contains  the  UJTL  task 
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elements.  The  Requirement  class  contains  the  requirement  elements  drawn  from 
governing  documentation. 
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^  Properties 
Q  Database 

Cl 
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Cl  DefinedTerm 
1^  Document  (5/5) 

Cl  DomainSet 
Exit 

Cl  ExternalFile 
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Cl  InterPace 
Cl  Issue  (3/3) 

Item  (44/44) 

Cl  Link 

Cl  Requirement  (147/147) 
Cl  Resource 
Cl  Risk 
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=  Cl  VeriPicationRequirement 
$■  Schema 
Ei  ^  Utilities 


Figure  10  -  CORE®  SE  Classes 


4.4.2  Establishing  Relationships 

Relationships  can  be  established  between  elements  of  different  classes  and  elements  of 
the  same  class.  This  can  be  accomplished  by  selecting  the  appropriate  type  of  relationship 
in  the  Relationships  field  as  shown  in  Figure  11. 
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Figure  11  -  Relationships 

This  figure  illustrates  relationships  between  elements  of  different  classes  or  of  the 
same  class. 


Figure  12  shows  some  of  the  key  types  of  relationships  allowed  in  the  CORE®  SE 
schema.  Additional  relationship  types  not  shown  in  the  figure,  such  as  generate  and 
generated  by,  were  used  to  tie  issues  to  functions.  If  a  function  element  does  not  have  a 
component  allocated,  an  Issue  element  is  generated.  Not  all  of  the  relationships  were  used 
for  the  MOC  project. 
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Figure  12  -  Key  SE  Relationships 

This  diagram  reflects  the  heart  of  the  systems  engineering  schema.  (Vitech 
Corporation,  2007) 
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For  the  MOC  project,  the  following  relationships  were  established: 

•  Category  categorizes  Requirement 

•  Requirement  refines  Requirement 

•  Function  allocated  to  Component 

•  Function  (sub-function)  decomposes  Function 

•  Function  generates  Issue 

•  Document  documents  Function,  Requirement,  Component 

Relationships  always  exist  in  both  directions;  however,  only  one  relationship  needs  to  be 
established  by  the  user.  Once  a  relationship  is  established  from  one  element,  CORE®  will 
automatically  establish  the  relationship  from  the  other  element.  For  example,  if  an 
allocated  to  relationship  is  established  from  the  Function  element  to  the  Component 
element,  CORE®  will  establish  a  performs  relationship  from  the  Component  element  to 
the  Function  element. 


4.4.3  Generating  Views 

The  effectiveness  of  using  CORE®  for  the  MOC  project  is  realized  by  the  different  views 
that  can  be  generated.  While  there  are  many  views  and  DODAF  artifacts  that  can  be 
generated  from  CORE®,  the  MOC  project  focuses  primarily  on  two,  the  Element 
Relationship  (ER)  diagrams  and  the  hierarchy  diagrams.  The  ER  diagram  for  an  element 
displays  all  the  direct  relationships  linked  to  that  element.  Two  examples  of  ER  diagrams 
are  shown  in  Figure  13  and  Figure  14.  Figure  13  shows  that  the  Falconview  system 
performs  Plan  Evacuation  Route  and  Develop  Base  Paragraphs  for  Operation  Plans  & 
Orders  functions.  Figure  14  shows  that  the  Provide  In-transit  Patient  Visibility  function  is 
allocated  to  four  systems,  possibly  indicating  capability  overlaps.  It  also  decomposes  the 
Coordinate  Patient  Movement  function,  indicating  that  it  is  a  child  activity  to  that 
function. 
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Figure  13  -  Element  Relationship  Diagram  of  the  Falconview  Component 
This  diagram  depicts  the  activities  to  which  the  Falconview  system  is  allocated 
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Figure  14  -  Element  Relationship  Diagram 

This  diagram  identifies  which  systems  have  been  allocated  to  accomplish  the 
assigned  activity. 
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Customizable  hierarchy  diagrams  can  also  be  generated,  showing  traceability  from  high 
level  functions  to  individual  systems.  Figure  15  shows  a  partial  view  of  the  hierarchy 
diagram  for  the  Assess  Effects  core  process.  As  shown  in  the  figure,  the  Assess  Effects 
core  process  was  decomposed  to  sub-functions  by  two  levels.  Those  sub-functions  were 
allocated  to  one  or  more  systems.  The  types  of  relationships  are  also  displayed. 


Figure  15  -  Partial  View  of  traceability 
This  diagram  illustrates  the  traceability  provided  by  CORE® 


4.4.4  Validation 

The  views  generated  by  CORE®  graphically  display  the  MOC  capability  gaps  and 
overlaps.  If  the  determination  was  made  that  no  system  can  fulfill  a  function,  a  GAP 
component  element  was  allocated  to  the  function.  In  Figure  16,  the  hierarchy  diagram 
shows  a  GAP  component  allocated  to  the  function.  In  addition  to  the  GAP  component,  an 
Issue  element  was  generated,  identifying  a  possible  issue  with  the  function.  If  multiple 
systems  were  allocated  to  a  function,  as  shown  in  Figure  17,  then  a  possible  capability 
overlap  was  indicated. 
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Figure  16  -  Capability  Gaps  in  the  CORE®  Model 
This  figure  illustrates  a  capability  gap  with  reasoning  assigned  as  an  Issue 


\ 


Figure  17  -  Capability  Overlaps  in  the  CORE®  Model 
This  illustrates  multiple  systems  assigned  to  a  single  activity 


Modeling  with  requirements  software  allowed  for  quick  identification  of  gaps  and 
traceability  to  core  processes.  As  new  systems  become  available  to  fill  those  gaps  the 
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model  can  be  updated  and  the  effects  of  those  changes  easily  identified.  Additionally, 
analysis  of  the  revised  model  will  identify  capability  overlaps. 


4.4.5  Challenges  of  Using  CORE® 

While  the  CORE®  software  provided  the  traceability  necessary  for  the  MOC  project,  it  is 
not  without  its  challenges,  and  there  were  several  encountered  when  using  CORE®  for 
this  project.  Since  none  of  the  team  members  were  familiar  with  the  software,  there  was  a 
steep  learning  curve  involved.  This  issue  was  overcome  by  completing  the  CORE® 
AutoLink  guided  tour  to  gain  familiarity  with  CORE®  MBSE  approach.  Since  the 
capstone  project  was  time  bounded,  the  extra  effort  expended  to  become  familiar  with  the 
software  put  a  strain  on  the  project. 

Limited  access  to  CORE®  also  posed  a  challenge.  The  software  was  only  available 
through  the  NFS  Virtual  SE  lab,  limiting  access  to  those  with  World  Wide  Web  access. 
The  software  does  not  have  the  capability  for  real-time  collaboration  with  multiple  users, 
slowing  the  progress  of  populating  the  model.  Only  one  user  could  work  on  the  data  file 
at  a  given  time.  A  situation  involving  the  licensing  of  CORE®  made  the  software 
inaccessible  for  14  days  at  the  beginning  of  the  third  quarter  of  the  Capstone  project. 
During  that  time,  work  continued  utilizing  Microsoft  Excel  to  establish  the  relationships. 
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5  SUMMARY,  CONCLUSIONS,  AND  RECOMMENDATIONS 


5.1  SUMMARY 

The  goal  of  this  project  was  to  identify  and  implement  a  methodology  for  conducting  an 
analysis  of  the  operational  capabilities  of  the  Maritime  Operations  Centers  (MOCs)  based 
on  assigned  baseline  systems  in  order  to  determine  if  the  capabilities  present  would  be 
sufficient  to  execute  the  mission  assigned  successfully.  The  methodology  selected 
involved  the  use  of  requirements  analysis  software  for  modeling  and  analysis  of  data 
extracted  from  MOC  documentation  obtained  from  various  sources,  with  emphasis  on 
traceability  to  requirements.  The  analysis  was  completed  and,  based  on  the  information 
available,  a  conclusion  was  reached  that  gaps  exist  in  the  functional  capabilities  of  the 
MOC;  therefore  preventing  the  ability  to  successfully  accomplish  all  assigned  missions. 


5.2  CONCLUSIONS 

As  stated  in  the  summary,  it  was  determined  that  several  capability  gaps  exist  if  only  the 
currently  planned  systems  are  available  in  the  MOC.  The  systems  assessed  were 
identified  in  the  Spiral  8  and  Spiral  10  baseline  memoranda  released  by  the  office  of  the 
Director  for  Warfare  Integration  (N6F).  Additional  systems  were  being  identified  for  the 
Spiral  12  build  concurrently  with  this  analysis,  but  a  definitive  list  of  systems  was  not 
available  for  inclusion  in  this  analysis. 


5.2.1  Requirements 

Requirements  traceability  was  the  foundation  of  the  analysis  conducted.  However, 
because  the  available  requirements  for  the  MOC  were  inconsistent  in  places  and  were  not 
validated,  the  analysis  of  capabilities  was  limited.  The  requirements  to  which  system 
capabilities  were  compared  were  drawn  from  governing  documentation,  but  were 
partially  “inferred”  by  the  project  team.  This  was  possible  because  involvement  with 
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various  MOC  working  groups  and  IPTs  allowed  team  members  to  become  familiar  with 
the  MOC  development  efforts  that  had  occurred  prior  to  commencing  the  project.  Some 
supporting  documentation  was  available,  but  configuration  management  appeared  not  to 
have  been  implemented  in  most  cases.  No  formal  documentation  of  requirements  has 
been  produced  (as  confirmed  by  the  SPAWAR  Technical  Authority  department)  and 
many  of  the  documents  used  to  create  the  supporting  architecture  views  have  been  drafts. 
It  is  unclear  if  the  draft  documents  can  be  considered  definitive  or  whether  there  are 
changes  that  have  not  yet  been  reflected  in  them.  At  the  time  this  analysis  was 
completed,  neither  updated  versions  of  requirements  documents  nor  architecture 
descriptions  have  been  located. 


5.2.2  Gaps 

Of  the  six  core  processes  that  comprise  the  MOC  functional  mission  areas  (Assess 
Effects,  Operational  Intelligence,  Operational  Planning,  Manage  Information,  Establish 
HQ,  and  Execute  Plans),  two  were  assessed  to  be  fully-mission  capable  using  current  and 
proposed  systems:  Assess  Effects  and  Operational  Intelligence.  The  remaining  four  had 
a  total  of  37  gaps  in  the  required  capabilities.  In  some  cases,  the  term  “gap”  could  imply 
that  insufficient  information  was  available  to  determine  which  system  should  be  assigned 
to  accomplish  the  activity;  therefore  it  was  not  possible  to  determine  if  the  required 
capability  existed.  Other  instances  were  attributed  to  the  appropriateness  of  the  level  in 
the  chain  of  command  associated  with  the  activity  descriptions.  Some  functions  appeared 
to  be  tactical  in  nature  and  the  team  concluded  it  would  be  inappropriate  for  a  command 
and  control  organization  to  execute  them.  Each  of  these  situations  resulted  in  assignment 
as  a  “potential  gap.”  In  cases  where  team  members  determined  that  none  of  the  systems 
present  were  capable  of  completing  the  required  tasks,  a  “true  gap”  resulted. 


A  limitation  of  this  study  was  the  team’s  lack  of  hands-on  experience  with  some  of  the 
relevant  systems.  The  number  of  potential  gaps  identified  in  this  analysis  illustrates  the 
need  for  subject  matter  expert  involvement.  The  assignment  of  systems  in  this  analysis 
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was  based  on  available  system  deseriptions  and  the  individual’s  interpretation  of  eaeh 
activity  that  comprised  the  core  processes.  Descriptions  of  systems  were  taken  at  face 
value  without  questioning  whether  they  were  optimistic  or  not.  Experts  more  familiar 
with  the  proposed  systems  might  find  more  gaps  than  those  identified  by  the  team.  They 
might  also  be  able  to  reclassify  potential  gaps  as  true  gaps.  Despite  this  limitation,  the 
methodology  applied  by  the  team  is  sound  and  will  facilitate  future  efforts. 


5.3  RECOMMENDATIONS 

5.3.1  Requirements 

The  most  important  recommendation  generated  as  a  result  of  our  project  is  for  the  Navy 
to  review  and  refine  the  MOC  requirements  and  validate  a  formal  requirements 
document.  Requirements  are  the  cornerstone  of  the  systems  engineering  process  (Buede, 
2000).  The  success  of  any  efforts  in  the  development  of  an  acquisition  program  hinges 
on  requirements.  It  is  impossible  to  determine  if  the  appropriate  capabilities  are  present 
if  requirements  that  define  the  functionality  to  be  achieved  are  incomplete  or  inconsistent. 


5.3.2  Use  of  Software 

A  significant  recommendation  for  a  program  development  of  this  size  is  to  incorporate 
the  use  of  requirements  software.  During  the  development  of  the  MOC  concept,  the 
number  of  functions  being  considered  as  relevant  or  necessary  by  the  working  group 
exceeds  1,000  and  continues  to  grow.  The  use  of  spreadsheets  to  capture  and  analyze  a 
collection  of  this  magnitude  is  inefficient  and  contributes  to  human  error  when 
implementing  practices  such  as  configuration  management,  traceability,  and  the 
determination  of  effects  caused  by  changing  the  elements  within  the  system.  The  ability 
to  establish  relationships  between  each  element  and  identify  traceability  to  requirements 
ensures  the  appropriate  functionality  is  maintained  and  the  effects  of  changing  system 
components  can  be  identified  and  mitigated.  The  subject  of  interoperability  was  briefly 
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discussed  in  this  report,  but  due  to  the  complexity  of  system  interfaces  it  was  not 
incorporated  into  the  analysis.  These  interfaces  can  also  be  identified  and  established 
with  the  help  of  the  automation  software.  This  will  ensure  interoperability  is  taken  into 
consideration  and  the  effects  identified  prior  to  incorporating  changes  to  system 
composition. 


5.3.3  Use  of  DoDAF  Schema 

Utilizing  a  modified  approach  to  the  analysis  could  provide  the  desired  gap  analysis  as 
well  as  additional  benefits.  The  use  of  the  DoDAF  schema  would  provide  a  more 
suitable  foundation  for  creating  a  detailed  information  architecture  and  a  functional 
model  of  the  MOC  network.  The  effort  would  still  utilize  the  tasks  that  comprise  the 
UJTLs,  mapping  them  to  operational  activities  and  subsequently  establishing 
relationships  to  functions  and  systems.  Identification  of  the  relationships  between  the 
activities  and  the  MOC  organizational  entities  responsible  for  each  action  would 
complete  the  information  flow  model.  Analysis  of  this  model  would  also  provide  the 
ability  to  determine  any  shortfalls  in  the  necessary  functionality. 


5.3.4  Incorporation  into  Spiral  12 

The  final  recommendation  is  to  incorporate  this  methodology  into  the  current  spiral  (12) 
development  of  the  MOC.  Doing  so  would  provide  visibility  of  potential  shortfalls  in  the 
work  conducted  to  date  while  providing  a  structured  approach  to  future  development 
efforts.  Validation  of  requirements  will  prevent  extraneous  effort  while  helping  to 
provide  focus  in  the  MOC  development  where  needed. 
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APPENDIX  A 

DETAILED  LISTS  OF  SYSTEMS  SYSTEM  ASSIGNMENTS 


The  tables  below  identify  functional  task  identifiers,  short  descriptors,  systems  assigned, 
and  gaps  where  system  assignment  was  not  possible. 


Table  8  -  Systems  Allocated  to  Assess  Effects  Functions 


Functions 

Systems 

AE.1.1 

Develop  Assessment  Plan 

GCCS-M 

AE.1.2 

Assess  Achievement  of  Desired  Effects 

GCCS-M 

AE.E2.1 

Develop  Combat  Assessment  Plan 

GCCS-M 

AE.E2.2 

Assess  Battle  Effects 

GCCS-M,  C2PC 

AE.E2.3 

Estimate  Initial  Damage 

GCCS-M 

AE.E2.4 

Estimate  Functional  Damage 

GCCS-M 

AE.E2.5 

Estimate  Ability  to  Reconstitute 

GCCS-M 

AE.E2.6 

Conduct  Weapons  Effectiveness  Assessment 

GCCS-M,  C2PC 

AE.E2.7 

Develop  Process  for  Monitoring  &  Understanding 
Operational  Environment 

GCCS-M 

AE.E2.8 

Provide  Feedback  on  Operations 

GCCS-M 

AE.E3 

Compare  Achieved  vs  Desired  Results 

GCCS-M,  C2PC 

AE.E4 

Determine  MOEs  Achieved 

GCCS-M,  ADSI,  C2PC 

AE.E7 

Determine  Success  or  Failure 

GCCS-M,  ADSI,  C2PC 

AE.E8 

Aggregate  Effects  Assessment 

GCCS-M 

AE.E5 

Determine  Unintended  Effects 

GCCS-M,  ADSI,  C2PC 

AE.E6 

Identify  and  Assess  Implications  of  Unintended  Effects 

GCCS-M 

Table  9  -  Systems  Allocated  to  Operational  Intelligence  Functions 


Functions 

Systems 

01.1.1 

Review  Mission  for  OPINTEL  Needs 

GCCS-M,  GCCS-I3 

01.1.2 

Develop  PIRs 

GCCS-M,  GCCS-I3 

01.1.2.1 

Analyze  OPLAN,  COAs  and  ECOAs  by  Phases 

GCCS-M,  GCCS-I3 

01.1.2.2 

Collate  Intelligence  Required  for  Operational  I&W 

GCCS-M,  GCCS-I3 

01.1.2.3 

Distill  Intelligence  Requirements 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.2.4 

Rank,  Prioritize  Intelligence  Requirements 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.2.5 

Determine  Intelligence  Vital  to  Mission  by  Phase  of  Op 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.3 

Identify  Intelligence  Knowledge  Gaps 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.4 

Generate  RFIs 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.5 

Develop  Draft  Collection  Plan 

GCCS-M,  GCCS-I3 

01.1.5.1 

Manage  Collection,  Intelligence  Requirements 

GCCS-M,  GCCS-I3 

01.1.5.1.1 

Identify  Collection  Requirements 

GCCS-M,  GCCS-I3 

01.1.5.1.2 

Validate  Collection  Requirement 

GCCS-M,  GCCS-I3 
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Table  9  -  Systems  Allocated  to  Operational  Intelligence  Functions  (continued) 


Functions 

Systems 

01.1.5.1.3 

Prioritize  &  Integrate  Collection  Requirements 

GCCS-M,  GCCS-I3 

01.1.5.1.4 

Forecast  Available  Collection  Assets 

GCCS-M,  GCCS-I3 

01.1.5.1.5 

Forward  CR  to  Next  Higher  Echelon 

GCCS-M,  GCCS-I3 

01.1.5.4 

Synchronize  ISR  with  Operations 

GCCS-M,  GCCS-I3 

01.1.5.9 

Visualize  ISR  Coverage  of  the  Operational  Environment 

GCCS-M,  GCCS-I3 

01.1.5.2 

Provide  Collection  Strategy 

GCCS-M,  GCCS-I3 

01.1.5.2.1 

Establish  Intelligence  Collection  Deadlines 

GCCS-M,  GCCS-I3 

01.1.5.2.2 

Develop  Collection  Strategy 

GCCS-M,  GCCS-I3 

01.1.5.2.3 

Determine  Friendly  ISR  Forces/Capability  (Organic) 

GCCS-M,  GCCS-I3 

01.1.5.2.4 

Prioritize  ISR  Options 

GCCS-M,  GCCS-I3 

01.1.5.2.5 

Select  ISR  Option 

GCCS-M,  GCCS-I3 

01.1.5.2.6 

Aggregate  Elements  of  Collection  Strategy 

GCCS-M,  GCCS-I3 

01.1.5.3 

Provide  Draft  ISR  Synchronization  Matrix 

GCCS-M,  GCCS-I3 

01.1.5.5 

Finalize  ISR  Synchronization  Matrix 

GCCS-M,  GCCS-I3 

01.1.5.6 

Develop  Draft  Collection  Plan 

GCCS-M,  GCCS-I3 

01.1.5.6.1 

Update  NAIs  &  Event  Template 

GCCS-M,  GCCS-I3 

01.1.5.6.2 

Confirm  Asset/Sensor  Availability 

GCCS-M,  GCCS-I3 

01.1.5.6.3 

Update  Environmental  Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.5.6.4 

Refme/Revise  Multi-INT  Collection  Plan 

GCCS-M,  GCCS-I3 

01.1.5.6.5 

Generate  Asset/Sensor/Placement/Route 

GCCS-M,  GCCS-I3 

01.1.5.6.6 

Apply  Airspace/Waterspace  Management  Procedures 

GCCS-M,  GCCS-I3 

01.1.5.6.7 

Aggregate  Elements  of  Collection  Plan 

GCCS-M,  GCCS-I3 

01.1.5.8 

Approve  Collection  Plan 

NCES;  IWS 

01.1.5.7 

Coordinate  Collection  Plan 

GCCS-M,  GCCS-I3 

01.1.6 

Process/Exploit  BA/ISR  Data 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.6.1 

Interpret  Sensor  Data 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.6.2 

Place  Raw  Data  into  Context 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.6.3 

Collate  BA/ISR  Data 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.6.4 

Correlate  BA/ISR  Data 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.6.5 

Fuse  ISR  Data 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.7 

Process  &  Exploit  Collected  Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.7.1 

Process  Operational  Environment  Information 
Distributively 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.7.2 

Integrate  Operational  Environment  Awareness 
Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.7.3 

Evaluate  Operational  Environment  Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.7.4 

Interpret  Operational  Environment  Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.7.5 

Fuse  Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 
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Table  9  -  Systems  Allocated  to  Operational  Intelligence  Functions  (continued) 


Functions 

Systems 

01.1.7.6 

ShareFused  Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.8 

Analyze  Operational  Environment  Information 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.1.9 

Update  IPOE 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

OI.l.lO 

Conduct  Predictive  Analysis 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.1 

Define  the  Environment 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.1.1 

Identify  Limits  of  Component  Commander's  Area  of 
Operations 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.1.2 

Determine  Significant  Characteristics  of  Operational 

Area 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.1.3 

Establish  Limits  of  Force's  Areas  of  Interest 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.1.4 

Determine  Full  Spectrum  of  Force's  Environment 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.1.5 

Determine  Environment  Detail  Required 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.2 

Analyze  the  Environment 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.2.1 

Analyze  Military  Aspects  of  Each  Dimension 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.2.2 

Evaluate  Effects  of  Each  Environment  Dimension  on 
Military  Operations 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.2.3 

Evaluate  Existing  Databases  &  Identify  Intel  Gaps  & 
Priorities 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.2.4 

Collect  Material  &  Intelligence  Required 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.2.5 

Confirm  Area/Country  Studies 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.3 

Analyze  Commander  Intent  &  Guidance 

GCCS-M,  GCCS-I3 

01.2.4 

Analyze  CCIR 

GCCS-M,  GCCS-I3 

01.2.5 

Evaluate  the  Adversary  (Phase  1) 

GCCS-M,  GCCS-I3 

01.2.5.1 

Identify  Adversary  Centers  of  Gravity 

GCCS-M,  GCCS-I3 

01.2.5.2 

Identify  Adversary  Objectives  &  Desired  End  State 

GCCS-M,  GCCS-I3 

01.2.5.3 

Analyze  Centers  of  Gravity  (Phase  1) 

GCCS-M,  GCCS-I3 

01.2.5.4 

Update  or  Create  Adversary  Models  (Phase  1) 

GCCS-M,  GCCS-I3 

01.2.5.5 

Identify  Adversary  Courses  of  Action 

GCCS-M,  GCCS-I3 

01.2.5.6 

Determine  Current  Adversary  Situation 

GCCS-M,  GCCS-I3 

01.2.5.7 

Determine  What  I&W  Would  Point  Toward  Likely 
Adversary  COA 

GCCS-M,  GCCS-I3 

01.2.5.8 

Identify  Adversary  Capabilities 

GCCS-M,  GCCS-I3 

01.2.5.9 

Update  Adversary  Patterns  of  Behavior 

GCCS-M,  GCCS-I3 

01.2.6 

Develop  Each  Adversary  COA 

GCCS-M,  GCCS-I3 

01.2.6.1 

Select  Adversary  Model  Representative  of  Considered 
Military  Ops 

GCCS-M,  GCCS-I3 

01.2.6.2 

Overlay  Doctrinal  Template  on  the  MCOO 

GCCS-M,  GCCS-I3 

01.2.6.3 

Adjust  Dispositions  to  Account  for  Environment  Effects 

GCCS-M,  GCCS-I3 
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Table  9  -  Systems  Allocated  to  Operational  Intelligence  Functions  (continued) 


Functions 

Systems 

01.2.6.4 

Depict  Location  &  Activities  of  all  HVTs  in  Adversary 
Model 

GCCS-M,  GCCS-13 

01.2.6.5 

Analyze&  Wargame  Adversary's  Likely  Scheme  of 
Maneuver 

GCCS-M,  GCCS-13 

01.2.6.6 

Refine  &  Re-evaluate  HVTs 

GCCS-M,  GCCS-13 

01.2.6.7 

Designate  Target  Areas  of  Interest  (TAls) 

GCCS-M,  GCCS-13 

01.2.7 

Evaluate  &  Prioritize  Each  Adversary  COA 

GCCS-M,  GCCS-13 

01.2.7.1 

Identify  Adversary  COA  Strengths  &  Weaknesses, 

COGs  &  Decisive  Points 

GCCS-M,  GCCS-13 

01.2.7.2 

Evaluate  How  Well  Adversary  COA  Meets  Established 
Criteria 

GCCS-M,  GCCS-13 

01.2.7.3 

Evaluate  How  Well  Adversary  COA  Takes  Advantage 
of  Environment 

GCCS-M,  GCCS-13 

01.2.7.4 

Determine  Which  COA  Offers  Greatest  Advantage  & 
Minimal  Risk 

GCCS-M,  GCCS-13 

01.2.7.5 

Consider  Adversary  May  Select  Other  COA 

GCCS-M,  GCCS-13 

01.2.7.6 

Analyze  Adversary  Activity  to  Determine  if  a  COA 
Selected 

GCCS-M,  GCCS-13 

01.2.7.7 

Identify  Adversary  Preparations 

GCCS-M,  GCCS-13 

01.2.8 

Identify  Initial  Collection  Requirements 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.2.9 

Prepare  &  Submit  IPOE  Products 

GALE,  JSIPS,  Analyst 

Notebook,  DCGS-N 

01.3.1 

Develop  Procedures  for  RFl  Submission 

NCES;  IWS 

01.3.2 

Develop  Feedback  Mechanism 

NCES;  IWS 

01.3.3 

Validate  RFl 

JDISS,  DCGS-N 

01.3.4 

Submit  RFl  to  HHQ 

JDISS,  DCGS-N 

01.3.5 

Answer  RFl 

JDISS,  DCGS-N 

01.3.6 

Track  RFls 

JDISS,  DCGS-N 

01.3.7 

Report  RFl  Status 

JDISS,  DCGS-N 

Table  10  -  Systems  Allocated  to  Operational  Planning  Functions 


Functions 

Systems 

OPP.1.3 

Approve/Modify  Mission  Statement 

JADOCS,  JCRE 

OPP.1.8 

Approve/Modify  COA 

JCRE,  ISPAN 

OPP.1.11 

Approve  Plans/Orders 

JCRE 

OPP.1.1 

Conduct  Operational  Mission  Analysis 

MIPS,  DCGS 

OPP.1.1.1 

Analyze  Higher  Commander's  Mission 

MIPS,  DCGS 

OPP.1.1. 2 

Develop  Objectives 

MIPS,  DCGS 

OPP.1.1. 3 

Determine  Specified,  Implied,  Essential  Tasks 

MIPS,  DCGS 

OPP.1.1. 4 

State  the  Purpose 

MIPS,  DCGS 

OPP.1.1. 5 

Identify  Externally  Imposed  Limitations 

MIPS,  DCGS 

OPP.1.1. 6 

Analyze  Available  Forces  and  Assets 

MIPS,  DCGS 

OPP.1.1. 7 

Determine  Critical  Factors,  COGs,  &  Decisive  Points 

IWS,  VISION 

OPP.1.1. 8 

Develop  Planning  Assumptions 

MIPS,  DCGS 

OPP.1.1. 9 

Conduct  Initial  Risk  Assessment 

MIPS,  DCGS 

OPP.1.1. 10 

Develop  Proposed  Mission  Statement 

MIPS,  DCGS 
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Table  10  -  Systems  Allocated  to  Operational  Planning  Functions  (continued) 


Functions 

Systems 

OPP.1.1.11 

Prepare  Mission  Analysis  Brief 

IWS,  VISION 

OPP.1.4 

Develop  CCIRs 

MIPS,  DCGS 

OPP.lAl 

Develop  Initial  CCIRs 

JADOCS 

OPP.  1.4.2 

Determine  Recommended  CCIRs 

Capability  Gap 

OPP.  1.4.3 

Approve  CCIRs 

JADOCS 

OPP.  1.7 

Develop  Courses  of  Action 

JADOCS,  GIANT 

OPP.  1.7.1 

Conduct  Pre-COA  Development  Analysis 

MIPS,  DCGS 

OPP.  1.7.2 

Develop  Courses  of  Action 

JADOCS,  GIANT 

OPP.  1.7.3 

Analyze  Courses  of  Action 

JADOCS,  GIANT 

OPP.  1.7.4 

Refine  Courses  of  Action 

JADOCS,  GIANT 

OPP.  1.7.5 

Perform  COA  Comparison 

JADOCS,  GIANT 

OPP.  1.7.6 

Develop  COA  Decision  Brief 

NCES 

OPP.  1.7.7 

Refine  IPOE  Based  on  COA  Comparison 

JADOCS,  GIANT 

OPP.  1.9 

Transition  to  Future  Operational  Planning 

JADOCS 

OPP.1.10 

Prepare  Plans/Orders 

JSIPS,  CPOF 

OPP.  1.10.1 

Plan  for  Actions  &  Resources  to  Achieve  Desired 
Effects 

GCCS-I3 

OPP.  1.10.2 

Develop  Base  Paragraphs  for  Operation  Plans  & 

Orders 

FalconView,  GCCS-I3 

OPP.  1.10.3 

Develop  Appropriate  Annexes,  Appendixes  &  Tabs 

Capability  Gap 

OPP.  1.10.4 

Confirm  Time-Phased  Force  &  Deployment  Data 
(TPFDD) 

GCCS-I3 

OPP.  1.10.5 

Assess  Risk  on  Plans/Orders 

DRRS 

OPP.  1.10.6 

Reconcile  Plans  and  Orders 

Capability  Gap 

OPP.1.10.7 

Back  Brief  &  Crosswalk  Orders 

Capability  Gap 

OPP.  1.10.8 

Coordinate  Plans  &  Tasking  with  other  Components 
&  Supporting  Organizations 

GCCS-M 

OPP.  1.12 

Transition  Orders  Development  to  Execution 

GCCS-M 

OPP.  1.12.1 

Establish  Maritime  Support  Request  Process 

MDA 

OPP.  1.12.2 

Identify  Maritime  Support  Requirements 

JADOCS 

OPP.1.12.3 

Coordinate  Maritime  Support  Requests 

JADOCS 

OPP.  1.12.4 

Adjudicate  Maritime  Support  Requests 

JADOCS 

OPP.  1.12.5 

Determine  Need  to  Modify  COA 

JADOCS,  SCOPES,  SBMCS, 
GIANT 

OPP.  1.12.6 

Synchronize  Tactical  Plans  &  Tasks 

DJC2 

OPP.  1.12.7 

Make  Maritime  Support  Requests  Visible/Accessible 

CANES 

OPP.2.1 

Analyze  Existing  OPORD  for  Operational 

Environment  Requirements 

JCRE 

OPP.2.3 

Analyze  Operational  Environment  Control  Measure 
Requests 

JCRE,  IWS,  MIPS 

OPP.2.5 

Develop  Initial  Set  of  Operational  Environment 

Control  Measures 

JCRE 

OPP.2.6 

Designate  Operational  Environment  Control  Sectors 

CNDE,  CANES,  NCES 

OPP.2.7 

Designate  Sector  Operational  Environment  Control 
Authorities 

CNDE,  CANES,  NCES 

OPP.2.8 

Establish  Operational  Environment  Change  Request 
Procedures 

CNDE,  CANES,  NCES 

OPP.2.9 

Compile  Operational  Environment  Control  Plan 

CNDE,  CANES,  NCES 

OPP.2.4 

Component  Sub  Control  Request  and  Control 
Discussions 

JCRE,  IWS,  MIPS 

53 


Table  10  -  Systems  Allocated  to  Operational  Planning  Functions  (continued) 


Functions 

Systems 

OPP.3.1 

Assess  CDRs  Guidance  for  10  Implications 

DJC2,  VISION 

OPP.3.2 

Determine  Most  Appropriate  Methods  to  Reach  10 
Objectives 

JADOCS,  VISION 

OPP.3.3 

Coordinate  Operations  Security 

VISION 

OPP.3.4 

Coordinate  Psychological  Operations 

VISION 

OPP.3.5 

Coordinate  Computer  Network  Operations 

VISION 

OPP.3.6 

Coordinate  Electronic  Warfare 

VISION 

OPP.3.7 

Coordinate  Military  Deception 

VISION 

OPP.3.8 

Integrate  Information  Operations  Plans 

RADIANT  MERCURY 

OPP.3.9 

Develop  10  Annex  C 

VISION 

OPP.4.1 

Establish  Exercise  Concept 

JSIPS 

OPP.4.2 

Assign  Personnel/Resources  to  Exercise 

DJC2 

OPP.4.3 

Develop  Participant  Instructions 

DJC2 

OPP.4.4 

Develop  Master  Scenario  Event  List 

ExMan,  JSIPS 

OPP.4.5 

Monitor  Exercise  Events 

ExMan,  JSIPS 

OPP.4.6 

Evaluate  Exercise 

ExMan,  JSIPS 

OPP.4.7 

Document  Exercise  Results 

ExMan,  JSIPS 

OPP.5.1 

Develop  Staff  Estimate 

JSIPS 

OPP.5.2 

Identify  Movement  Requirement 

JCRE 

OPP.5.2.1 

Estimate  Lift  Requirements 

GCCS-M 

OPP.5.2.2 

Describe  Requirements  in  Logistics  Terms 

JCRE 

OPP.5.2.3 

Estimate  Transportation  Requirements 

GCSS-CC/JTF,  CFAST 

OPP.5.2.4 

Submit  Transportation  Requirements  &  Report 

GCSS-CC/JTF,  CFAST 

OPP.5.3 

Identify  Transportation  Requirements 

GCSS-CC/JTF,  CFAST 

OPP.5.4 

Assess  Logistical  Capability  Organic/Inorganic 
Requirement 

GCSS-CC/JTF,  CFAST 

OPP.5.4.1 

Anticipate  Capabilities  &  Logistics  Needs 

GCSS-CC/JTF,  CFAST 

OPP.5.4.2 

Develop  Logistics  COA 

GCSS-CC/JTF,  CFAST 

OPP.5.4.3 

Monitor  Strategic/Operational  Tactical  Situation 

GCSS-CC/JTF,  CFAST 

OPP.5.4.4 

Develop  &  Maintain  Logistics  COP 

GCSS-CC/JTF,  CFAST 

OPP.5.4.5 

Coordinate  Field  service  Requirements 

GCSS-CC/JTF,  CFAST 

OPP.5.8 

Maintain  Logistics  Knowledge  Base 

GCSS-CC/JTF,  CFAST 

OPP.5.9 

Terminate  Sustainment 

GCSS-CC/JTF,  CFAST 

OPP.5.5 

Prioritize  &  Time  Phase  Requirements 

GCCS-I3 

OPP.5.6 

Prepare  Transportation  Plans/Orders 

GCSS-CC/JTF,  CFAST 

OPP.5.6.1 

Plan  Transportation  Operations 

GCSS-CC/JTF,  CFAST 

OPP.5.6.2 

Apportion  Transportation 

GCSS-CC/JTF,  CFAST 

OPP.5.6.3 

Allocate  Transportation 

GCSS-CC/JTF,  CFAST 

OPP.5.6.4 

Establish/Manage  Transportation  Request  Process 

GCSS-CC/JTF,  CFAST 

OPP.5.6.5 

Validate  Transportation  Request 

GCSS-CC/JTF,  CFAST 

OPP.5.6.6 

Task  Transportation  Assets 

GCSS-CC/JTF,  CFAST 

OPP.5.7 

Plan  &  Coordinate  Embarkation/Debarkation 

GCSS-CC/JTF,  CFAST 

OPP.5.7.1 

Prepare  Forces  for  Movement 

GCSS-CC/JTF,  CFAST 

OPP.5.7.2 

Establish  Movement  Criteria 

GCSS-CC/JTF,  CFAST 

OPP.5.7.3 

Coordinate  Movement 

GCSS-CC/JTF,  CFAST 

OPP.5.7.4 

Validate  Shipment 

GCSS-CC/JTF,  CFAST 

OPP.5.10 

Redeployment 

GCSS-CC/JTF,  CFAST 

OPP.6.1 

Examine  Space  Resources 

SCOPES 

OPP.6.2 

Identify  Space  Assumptions 

JWS 
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Table  10  -  Systems  Allocated  to  Operational  Planning  Functions  (continued) 


Functions 

Systems 

OPP.6.3 

Analyze  Space  Capability 

JWS 

OPP.6.4 

Analyze  Foreign  Space  Reliance 

JWS 

OPP.6.5 

Identify  Political  Constraints 

JWS 

OPP.6.6 

Develop  Space  Tactics 

JWS 

OPP.6.7 

Define  Space  Responsibilities 

JWS 

OPP.6.8 

Identify  Space  Logistics  Requirements 

JWS 

OPP.6.9 

Identify  Space  Augmentation  Requirements 

JWS 

OPP.6.10 

Integrate  Space  Plan 

JWS 

OPP.7.1 

Establish  Salvage  &  Equipment  Retrograde  Measures 

GCSS-CC/JTF,  CFAST,  JCRE 

OPP.7.2 

Send  Equipment  Retrograde  Information 

GCSS-CC/JTF,  CFAST,  JCRE 

OPP.7.3 

Identify  Recoverable  or  Salvageable  Gear 

GCSS-CC/JTF,  CFAST,  JCRE 

OPP.7.4 

Coordinate  &  Conduct  Equipment  Recovery 

GCSS-CC/JTF,  CFAST,  JCRE 

Table  11  -  Systems  Allocated  to  Manage  Information  Functions 


Functions 

Systems 

MLl.l 

Ensure  Authorized  Entities  &  Information  Used 

Capability  Gap 

ML  1.2 

Adapt  info  Sharing  to  Accommodate  Evolving  Needs 

Capability  Gap 

ML  1.3 

Manage  Information  Management  Cell 

Capability  Gap 

ML  1.3.1 

Manage  Workgroup  Managers  (embedded/shared) 

Capability  Gap 

MLl.3.2 

Provide  Overall  Info-Related  Admin  Support 

MSRT 

MLl.3.3 

Manage  Electronic  File  Plan 

Capability  Gap 

MLl.3.4 

Manage  Messaging  Services 

TBMCS,  DJC2 

MLl.3.5 

Manage  Suspense  Control 

Capability  Gap 

MLl.3.6 

Provide  Component  IM  Cell  Services 

Capability  Gap 

ML  1.4 

Provide/Publish  Data/Information  to  Net-Centric 
Environment 

CNDE,  CANES 

ML  1.4.1 

Generate  Discovery  Metadata 

CMA 

ML  1.4.2 

Associate  Semantic  and  Structural  Metadata 

CNDE,  CANES,  CMA 

ML  1.4.3 

Identify  Data/Information  Requirements 

COLISEUM 

ML  1.4.4 

Prioritize  Data/Information  Requirements 

MSRT 

ML  1.4.5 

Designate  Reporting  Requirements 

COLISEUM 

ML  1.4.6 

Request  Data/Information 

MSRT 

ML  1.4.7 

Make  Data/Information  Requirements  Visible  & 
Accessible 

MDA 

ML  1.4.8 

Develop  Data/Information 

Capability  Gap 

ML  1.4.9 

Publish  Data/Information 

NCES 

ML  1.5 

Conduct  Data  Management 

CNDE,  CANES 

ML  1.5.1 

Establish  Database  Management  Procedures 

C2PC,  TDBM,  TCO 

MLl.5.2 

Conduct  Distributed  Archive 

CNDE,  CANES 

ML  1.5.3 

Determine  Information  Pedigree 

Capability  Gap 

ML  1.5.4 

Maintain  Information  Pedigree 

Capability  Gap 

MLl.5.5 

Catalogue  Information 

CMMA 

MLl.5.6 

Store  Information 

CANES/NCES 

MLl.5.7 

Dispose  of  Information 

CMMA 

ML  1.6 

Capture,  Obtain  &  Distribute  Lessons  Learned 

IWS 

ML  1.7 

Establish  Digital  Rules  of  Protocol 

Capability  Gap 
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Table  11  -  Systems  Allocated  to  Manage  Information  Functions  (continued) 


Functions 

Systems 

ML  1.8 

Collect  Data  Information 

CMMA,  GFM 

ML  1.8.1 

Identify  Data/Information  Assets 

CMA 

ML  1.8.2 

Prioritize  Data/Information  Assets 

CMA 

ML  1.8.3 

Identify  Subscription 

Capability  Gap 

ML  1.8.4 

Request  Subscription 

Capability  Gap 

MLl.8.5 

Access  Data/Information 

CNDE,  CANES 

MLl.8.6 

Evaluate  Subscribed  Data/Information 

Capability  Gap 

ML  1.8.7 

Update  Subscription 

Capability  Gap 

MLl.8.8 

Formulate  Discovery  Search 

Capability  Gap 

MLl.8.9 

Discover  Services 

NCES 

ML  1.9 

Document  Info  Requirements/General  Procedures 

NCES 

ML  1.10 

Process  Data/Information  Distributive^ 

CNDE,  CANES 

ML  1.10.1 

Filter  Data/Information 

GALE-Lite 

ML  1.10.2 

Deconflict  Data/Information 

COLISEUM 

ML  1.10.3 

Aggregate  Data/Information 

CNDE,  CANES 

ML  1.1 0.4 

Correlate  Data/Information 

NCCT,  C2PC 

MLl.10.5 

Perform  Data/Information  Transformation 

DCTS 

MLl.10.6 

Integrate/Fuse  Data/Information 

MDA 

ML  1.10.7 

Label  Data/Information 

Radiant  Mercury,  CENTRIXS 

Ml.l.ll 

Share  Information  Across  Forces,  COls  & 

Communities  of  Practice 

MDA,  NCES 

ML  1.12 

Determine  if  Info  Sharing  Meets  COls  &  CofPs  Needs 

MDA 

ML2.1 

Develop  Procedures  for  RFl  Submission 

MASTER,  NCES,  NIPRNET, 
SIPRNET 

ML2.2 

Implement  RFl  Procedures 

MASTER,  NCES,  NIPRNET, 
SIPRNET 

ML2.3 

Validate  RFl 

MASTER,  NCES,  NIPRNET, 
SIPRNET 

ML2.4 

Track  RFls 

MASTER,  NCES,  NIPRNET, 
SIPRNET 

ML2.5 

Draft  Response  to  RFl 

MASTER,  NCES,  NIPRNET, 
SIPRNET 

ML2.6 

Submit  RFl  to  HHQ 

MASTER,  NCES,  NIPRNET, 
SIPRNET 

ML2.7 

Disseminate  RFl  Response 

MASTER,  NCES,  NIPRNET, 
SIPRNET 

ML3.1 

Provide  Information  Governance 

CMMA 

ML3.2 

Plan  Information  Management 

GCCS 

ML3.4 

Compile  IMP  Input 

GCCS 

ML3.5 

Approve  Component  IMP 

IWS,  NIPRNET,  SIPRNET, 

NCES 

ML3.3 

Coordinate  IMP 

Capability  Gap 

ML4.1 

Assess  Battle  Rhythm 

GCCS,  DRRS,  DJC2 

ML4.2 

Align  with  HHQ  Battle  Rhythms 

NCES 

ML4.3 

Adjust  Battle  Rhythm 

C2PC,  NCES 

ML4.4 

Approve  /Document  Commander's  Battle  Rhythm 

NCES 

ML5.1 

Identify  C2  &  Communications  Resource  Requirements 

GCCS-M 

ML5.2 

Tailor  C2  Systems  &  Communications  Resources  as 
Required 

DJC2 

ML5.2.5 

Manage  Net-Centric  Environment  Operations 

CNDE,  CANES 
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Table  11  -  Systems  Allocated  to  Manage  Information  Functions  (continued) 


Functions 

Systems 

ML5.3 

Coordinate  C2  &  Communications  Resource 
Requirements 

GCCS-M 

ML5.4 

Promulgate  Force  Communications  Plan 

Vision 

ML5.5 

Locate  Service 

GCSS-CC/JTF/JTF 

ML5.6 

Connect  to  Service 

GCSS-CC/JTF/JTF 

ML5.7 

Login  to  Service 

GCSS-CC/JTF/JTF 

ML5.8 

Access  Authorized  Service 

GCSS-CC/JTF/JTF 

ML5.9 

Manage  Net-Centric  Environment  Operations 

CNDE,  CANES,  CENTRIXS 

ML5.10 

Monitor  Component  Comm  Links  &  Networks 

CENTRIXS,  NERMS 

ML6.1 

Provide  Computer  Network  Defense  Services 

Capability  Gap 

ML6.2 

Configure  Protection  Capabilities 

NIPRNETnet,  SIPRNETnet 

ML6.3 

Coordinate  Computer  Network  Operations 

CENTRIXS 

ML6.4 

Monitor  Information  Environment 

CENTRIXS 

ML6.5 

Detect  Unauthorized  Action 

NIPRNETnet,  SIPRNETnet, 
NERMS 

ML6.6 

Analyze  Network  Anomalies 

CENTRIXS,NIPRNETnet, 

SIPRNETnet 

ML6.7 

Respond  to  Network  Incident 

NIPRNETnet,  SIPRNETnet 

Table  12  -  Systems  Allocated  to  Establish  Headquarters  Functions 


Functions 

Systems 

EHQ.LI 

Establish  Appropriate  Organizational  Relationships 

GCCS-M 

EHQ.L6 

Connect  &  Interface  with  Non-DoD  Organizations 

GCCS-M 

EHQ.L7 

Establish  Role-Based  Knowledge  Framework 

GCCS-M 

EHQ.L8 

Form  Distributed  Teams/COIs/CofP 

GCCS-M,  GCSS 

EHQ.L8.I 

Access  Subject  Matter  Expert  &  Essential 

Information 

GCCS-M,  GCSS 

EHQ.  1.8.2 

Identify  COI/CofP 

GCCS-M 

EHQ.I.8.3 

Establish  COI/CofP 

GCCS-M 

EHQ.  1.8.4 

Develop  COI/CofP  Charter 

GCCS-M 

EHQ.I.8.5 

Prioritize  Information  Sharing  Capabilities 

GCCS-M,  GCSS 

EHQ.I.8.6 

Identify  Related  COIs/CofPs 

GCCS-M,  GCSS 

EHQ.  1. 8.7 

Advertise  COI/CofP 

GCCS-M,  GCSS 

EHQ.I.8.8 

Provide  COI/CofP  Environment 

GCCS-M,  GCSS 

EHQ.I.8.9 

Participate  in  COI/CofP 

GCCS-M,  GCSS 

EHQ.I.8.I0 

Manage  &  Govern  COI/CofP 

GCCS-M,  GCSS 

EHQ.  1.9 

Manage  Battle  Rhythm 

GCCS-M,  GCSS 

EHQ.I.IO 

Implement  Best  Practices 

NCES,  NIPRNETNET, 
SIPRNETNET,  VTC 

EHQ.  1. 2 

Allocate  Decision  Authority/Rights 

GCCS-M,  GCCS-J,  CENTRIX- 
M 

EHQ.  1. 3 

Delegate  Organizational  Authority  for  Mission 
Planning  &  Execution 

GCCS-M,  GCCS-J,  CENTRIX- 
M 

EHQ.  1.4 

Deploy  MOC  Forward  Element 

GCSS,  GCCS-M,  DJC2,  C2PC, 
GCCS-J 

EHQ.  1.4. 1 

Identify  Forward  Element  Requirements 

GCSS,  GCCS-M,  DJC2 

57 


Table  12  -  Systems  Allocated  to  Establish  Headquarters  Functions  (continued) 


Functions 

Systems 

EHQ.  1.4.2 

Survey  Prospective  Deployment  Site 

GCSS,  GCCS-M,  C2PC,  DJC2 

EHQ.  1.4.3 

Develop/Update  Threat  Assessment 

GCSS,  GCCS-M,  DJC2 

EHQ.  1.4.4 

Develop/Update  Vulnerability  Assessment 

GCSS,  GCCS-M,  DJC2 

EHQ.  1.4.5 

Develop  Criticality  Assessment 

GCSS,  GCCS-M,  DJC2 

EHQ.  1.4.6 

Plan  for  Host  Nation  Support 

GCCS-J 

EHQ.  1.4.7 

Establish  &  Coordinate  Security  Procedures  for 

Theater  Forces  &  Means 

GCSS,  GCCS-M,  DJC2 

EHQ.  1.4.8 

Establish  Collaboration  Sessions  on  the  Fly  during 
Operations 

GCSS,  GCCS-M,  NCES 

EHQ.  1.4.9 

Manage  Means  of  Communicating  Operational 
Information 

GCSS,  GCCS-M 

EHQ.  1.4. 10 

Assess  Effectiveness  of  C4  Systems 

GCSS,  GCCS-M 

EHQ.  1.4. 11 

Obtain  Lodging  for  Personnel 

DTS 

EHQ.  1.5 

Transition  Role  of  HQ 

GCCS-M 

EHQ.  1.5.1 

Establish  Command  Transition  Criteria  &  Procedures 

GCCS-M 

EHQ.1.5.2 

Establish  Command  Relationships  to  Enable 
Appropriate  Coordination 

GCCS-M 

EHQ.1.5.3 

Develop  Joint  Force  Liaison/Augmentee  Structure 

GCCS-M,  GCCS-J 

EHQ.  1.5.4 

Establish  Internal  Staff  Collaboration  Structures  & 
Processes 

GCCS-M 

EHQ.1.5.5 

Define  Specific  Procedures  for  Allocating 
Capabilities/F  orces 

GCCS-M 

EHQ.1.5.6 

Define  Specific  Procedures  for  Exercising 
Capabilities/F  orces 

GCCS-M 

EHQ.1.5.7 

Define  Specific  Procedures  for  Tasking 

Capabilities/F  orces 

GCCS-M 

EHQ.1.5.8 

Define  Specific  Procedures  for  Transitioning  C2 

GCCS-M 

EHQ.1.5.9 

Execute  C4  Policies  &  Procedures  for  the  Joint 
Operations  Area 

GCCS-J,  DCGS-N,  TBMCS, 
CENTRIX-M 

EHQ.1.11 

Sub  Component  Interagency 

Capability  Gap 

EHQ.2.1 

Develop  Training  Plans  and  Programs 

GCCS-M 

EHQ.2.2 

Provide/Execute  Training  for  U.S.  and  Other  Nation 
Units  and  Individuals 

GCCS-M 

EHQ.2.3 

Assess  Training 

CENTRIX-M,  GCCS-J,  NCES 

Table  13  -  Systems  Allocated  to  Execute  Plans  Functions 


Functions 

Systems 

EP.1.1 

Maintain  Operational  Information  &  Joint/Naval  Forces 
Status 

JADOCS 

EP.1.1.1 

Monitor  Data  Feeds  to  CIP/CTP/COP 

DCGS-N,  ADSI,  C2BMC 

EP.1.1.2 

Maintain  Common  Intelligence  Picture 

CMMA 

EP.1.1.3 

Integrate  Adversary  &  Friendly  Data 

JADOCS 

EP.1.1.4 

Manage  Common  Tactical  Picture  (CTP) 

C2PC 

EP.1.1.5 

Integrate  Common  Tactical  Pictures 

C2PC 

EP.1.1.6 

Manage  COP  Tracks 

C2PC 

EP.1.1.7 

Update  COP  Information 

C2PC 

EP.1.1.8 

Add  Amplifying  Info  to  Tracks 

JADOCS,  C2PC 

EP.1.1.9 

Sanitize  COP 

C2PC 
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Table  13  -  Systems  Allocated  to  Execute  Plans  Functions  (continued) 


Functions 

Systems 

EP.1.1.10 

Disseminate  COP 

JADOCS 

EP.1.1.11 

Assess  COP  Information 

JADOCS,  C2PC 

EP.EE12 

Collate  COP  Information 

JADOCS 

EP.EE13 

View  Tailored,  Relevant  Situational  Information 

DCGS-N,  JADOCS 

EP.E2 

Assure  Adequate  Control,  Tracking  &  Management  of 
Plans  &  Decisions 

C2PC 

EP.E4 

Execute  Plans/Orders 

JWICS,  SVOIP,  M3 

EP.E5 

Conduct  Operational  Movement  &  Maneuver 

DCGS-N,  JADOCS,  C2PC 

EP.E5.1 

Deconflict  the  Operational  Environment 

DCGS-N,  JADOCS,  C2PC 

EP.E5.2 

Direct  Operational  Movement 

JADOCS 

EP.E5.3 

Control  Movement 

C2PC 

EP.E5.4 

Provide  Joint  Total  Asset  Visibility 

DCGS-N 

EP.E5.5 

Provide  Status  of  Deployment  Operations 

DCGS-N,  JADOCS,  C2PC 

EP.E5.6 

Conduct  Operational  Maneuver  &  Force  Positioning 

JADOCS,  C2PC 

EP.E5.7 

Provide  Operational  Mobility 

JADOCS,  C2PC 

EP.E6 

Monitor  Execution  &  Adapt  Operations 

DCGS-N 

EP.E6.1 

Monitor  Execution  of  Plans/Orders 

M3,  DCGS-N 

EP.E6.2 

Manage  Risk 

GCCS-M/J 

EP.E6.3 

Intervene  in  Subordinate  Actions  as  Needed 

C2PC 

EP.E6.4 

Adapt  Operations  to  Changing  Situations  thru  Initiative 
&  Self  Synchronization 

JADOCS,  C2PC 

EP.E6.5 

Modify/Revise  Procedures  &  Schedules 

C2PC 

EP.E6.6 

Respond  to  Emerging  Requests  for  Support  from 
Peer/Subordinate  Commands 

C2PC 

EP.E3 

Synchronize  Execution  Across  All  Domains 

JADOCS,  C2PC 

EP.E7 

Collaboratively,  Rapidly  Replan  Operations 

C2PC 

EP.2.1 

Approve  Planning  Guidance 

C2PC 

EP.2.2 

Develop  Priority  of  Effort 

GCCS-M/J/I3 

EP.2.3 

Shape  Guidance  w/Mission  Partners'  Concerns  in  Mind 

GCCS-J 

EP.2.4 

Develop  the  Commander's  Planning  Guidance 

GCCS-M/J/I3 

EP.2.5 

Make  Commander's  Planning  Guidance 

V  isible/Accessible 

NCES 

EP.3.1 

Request  Health  Services  Support 

NCES 

EP.3.2 

Coordinate  Health  Service  Allocation 

DCGS-N,  NCES 

EP.3.3 

Submit  Patient  Movement  Request 

M3 

EP.3.4 

Transmit  MEDEVAC  OPS  Info 

M3 

EP.3.5 

Receive  MEDEVAC  OPS  Coordination  Info 

NCES,  M3 

EP.3.6 

Coordinate  Patient  Movement 

GCCS-M/J,  NCES 

EP.3.6.1 

Administratively  &  Clinically  Validate  Patient 

Capability  Gap 

EP.3.6.2 

Locate  Appropriate  Medical  Facilities 

NCES,  NIPRNET,  SIPRNET 

EP.3.6.3 

Identify  Evacuation  Resources 

GCCS-M/J,  NCES,  DCGS-N 

EP.3.6.4 

Integrate  &  Synchronize  the  Resources  for  Patient 
Evacuation 

GCCS-M/J 

EP.3.6.5 

Plan  Evacuation  Route 

Falconview 

EP.3.6.6 

Provide  Patient  Attendants  &  Movement  Items 

Capability  Gap 

EP.3.6.7 

Move  Patient 

Capability  Gap 

EP.3.6.8 

Provide  In-transit  Patient  Visibility 

DCGS-N,  NCES 

EP.3.7 

Conduct  Patient  Evacuation 

Capability  Gap 

EP.3.8 

Obtain  &  Analyze  Medical  Information 

NCES 
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Table  13  -  Systems  Allocated  to  Execute  Plans  Functions  (continued) 


Functions 

Systems 

EP.3.9 

Manage  Blood  Program  in  Area  of  Operations 

C2PC 

EP.4.1 

Receive  Request  for  Frequency  Assignment 

IWS,  Outlook 

EP.4.2 

Analyze  and  Ensure  Spectrum  Availability 

AESOP 

EP.4.3 

Develop  Electromagnetic  Frequency  Assignments 

AESOP,  C2PC 

EP.4.5 

Resolve  Interference  &  Electromagnetic  Effects  Issues 

AESOP 

EP.4.4 

Deconflict  Spectrum  Usage 

IWS,  Outlook 

EP.5.1 

Monitor  &  Analyze  Current  &  Projected  Unit  Personnel 
Strengths 

DRRS 

EP.5.2 

Initiate  Personnel  Staff  Estimates 

IWS,  NCES,  NIPRNET, 

SIPRNET,  VTC 

EP.5.3 

Determine  Effects  of  Personnel  Strengths  on  Assigned 
Operations 

DRRS 

EP.5.4 

Provide  Headquarters  Personnel  &  Infrastructure 

Capability  Gap 

EP.5.4.1 

Receive  Personnel  Request 

NCES,  M3 

EP.5.4.2 

Transmit  Personnel  Allocation  Information 

NCES,  M3 

EP.5.4.3 

Provide  Augmentation 

Capability  Gap 

EP.5.4.4 

Control  Throughput  of  Personnel  and  MPE/S 

NCES 

EP.5.4.5 

Request/Receive  Personnel  Information 

NCES 

EP.5.4.6 

Send  Personnel  Transfer  Information 

NCES 

EP.5.5 

Process  Manpower  Management  System  Data 

DRRS 

EP.5.6 

Provide  Personnel  Accounting  and  Strength  Support 

NCES 

EP.5.7 

Provide  for  Personnel  Services 

Capability  Gap 

EP.5.8 

Joint  Reception  Process 

DRRS 

EP.6.9 

Mission  Planning  &  Force  Execution 

DCGS-N,  ADSI,  C2BMC, 
JADOCS 

EP.6.1 

Develop  Maritime  End  State  and  Objectives 

NCES 

EP.6.2 

Perform  Target  Development  and  Priorities 

C2BMC,  JADOCS 

EP.6.3 

Capabilities  Analysis 

NCES 

EP.6.4 

Develop  Operational  Targets 

NCCT,  JADOCS 

EP.6.5 

Develop  Maritime  Target  List 

NCCT,  JADOCS 

EP.6.6 

Provide  Maritime  Target  Process  Decision 

NCCT,  JADOCS 

EP.6.7 

Provide  Target  Nominations  to  Higher  HQ 

NCCT,  C2BMC,  JADOCS 

EP.6.8 

Commander's  Decision  &  Force  Appointment 

JMPS,  C2BMC,  JADOCS 

EP.6.10 

Prioritize  &  Integrate  Collection  Requirements 

DCGS-N,  C2BMC 

EP.6.11 

Conduct  Weaponeering 

JADOCS 

EP.6.12 

Conduct  Force  Allocation  &  Assessment 

JMPS 

EP.6.13 

Develop  Mission  Timing  &  Synchronization 

JMPS 

EP.6.14 

Develop  tasking  Orders  to  Maritime  Forces 

JMPS 

EP.6.15 

Process  JIP  TL/JIP  CL/Asset  Appointment 

Capability  Gap 

EP.7.1 

Forecast  Vulnerability  of  Friendly  Operations 

SCOPES,  SBMCS 

EP.7.2 

Recommend  Force  Enhancement  Options 

SCOPES 

EP.7.3 

Coordinate  Space  Control  Assets 

SCOPES,  DMS,  GCCS-J 

EP.7.4 

Deconflict  Use  of  DoD  Space  Systems 

SCOPES,  DMS,  GCCS-J 

EP.7.5 

Provide  Tailored  Space  Training 

Capability  Gap 

EP.7.6 

Distribute  Missile  Warning  Data 

ADSI,  C2BMC,  DMS,  GCCS-J 

EP.8.1 

Develop  MOEs  for  Determining  if  Collection  Tasks 

Are  Being  Answered 

IWS,  NIPRNET,  SIPRNET, 

NCES,  VTC 

EP.8.2 

Monitor  &  Evaluate  Collection  Strategies  for 
Effectiveness 

DCGS-N,  NCES 
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Table  13  -  Systems  Allocated  to  Execute  Plans  Functions  (continued) 


Functions 

Systems 

EP.8.3 

Assess  RFI/CR  Fulfillment 

NCES 

EP.8.4 

Assess  Sensor  Grid  Status,  Configuration,  Performance 
&  Capabilities 

DCGS-N 

EP.8.6 

Provide  Operational  Environment  Awareness 

Operations  Assessment 

DCGS-N 

EP.8.5 

Identify  Coverage  Gaps  &  Redundancies,  Consider 

REF 

NCES 

EP.9.1 

Execute  Logistics  Plans  within  Assigned  Operational 
Area  -  Classes  1  thru9 

Global  Trader,  GCSS(Thin) 

EP.9.2 

Develop/Maintain  Logistics  Base  in  JOA 

Capability  Gap 

EP.9.3 

Anticipate  Response  to  Force  Needs 

Global  Trader,  GCSS(Thin) 

EP.9.4 

Provide  for  Movement  in  the  Area  of  Operations 

Global  Trader,  GCSS(Thin) 

EP.9.5 

Track  &  Manage  Supplies 

Global  Trader,  NCES, 

GCSS(Thin) 

EP.9.6 

Coordinate  Ordnance  Requirements 

Global  Trader,  GCSS(Thin) 

EP.9.7 

Coordinate  POL  Requirements 

Global  Trader,  GCSS(Thin) 

EP.9.8 

Provide  for  Sustainment  of  Equipment  in  the  JOA 

Global  Trader,  GCSS(Thin) 

EP.9.8.1 

Predict  Repair/Maintenance  Requirements 

Capability  Gap 

EP.9.8.2 

Sense  Repair/Maintenance  Requirements 

Capability  Gap 

EP.9.8.3 

Monitor  Maintenance  Capabilities  &  Status  within  the 
JOA 

NCES 

EP.9.8.4 

Identify  Repair/Maintenance  Resources 

NCES 

EP.9.8.5 

Establish  Maintenance  Priorities 

Global  Trader,  GCSS(Thin) 

EP.9.8.6 

Receive  Maintenance  Schedule 

M3,  SharePoint,  Outlook 

EP.9.8.7 

Provide  Maintenance  Schedule 

M3,  SharePoint,  Outlook 

EP.9.8.8 

Provide  Shipboard  &  Mobile  Maintenance  to  Embarked 
Force 

Global  Trader,  GCSS(Thin) 

EP.9.9 

Coordinate  Support  for  the  Forces  in  the  JOA 

Global  Trader,  C2PC,  NCES, 
GCSS(Thin) 

EP.9.9.1 

Receive  Supply  Allocation  Information 

Global  Trader,  GCSS(Thin) 

EP.9.9.2 

Report  Demand  &  Supply  Transactions 

Global  Trader,  DCGS-N,  C2PC, 
GCSS(Thin) 

EP.9.9.3 

Sense  Demand  for  Logistics  Resources 

Global  Trader,  DCGS-N  C2PC, 
GCSS(Thin) 

EP.9.9.4 

Analyze  Evolving  Capabilities  &  Sustainment 
Requirements 

NCES 

EP.9.9.5 

Process  Transportation  Request 

Global  Trader,  DCGS-N,  C2PC, 
GCSS(Thin) 

EP.9.9.6 

Schedule/Coordinate  Replenishment 

Global  Trader,  DCGS-N, 
GCSS(Thin) 

EP.9.10 

Monitor  Critical  Supply  Support  Capabilities 

Global  Trader,  DCGS-N,  C2PC, 
GCSS(Thin) 

EP.10.2 

Configure  Netted  Sensor  Grid 

Capability  Gap 

EP.10.3 

Task  Sensor 

Capability  Gap 

EP.10.4 

Collect  &  Transport  Sensor  Derived  Data 

DCGS-N 

EP.10.4.1 

Collect  Data 

DCGS-N 

EP.10.4.2 

Provide  Sensor  Data 

DCGS-N 

EP.10.4.3 

Conduct  Dynamic  Cross-Cuing  of  Sensor  Data 

Capability  Gap 

EP.10.4.4 

Provide  Sensor  Tip-Off 

Capability  Gap 

EP.10.4.5 

Capture  Sensor  Platform  Data 

DCGS-N,  GALE-Lite 
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Table  13  -  Systems  Allocated  to  Execute  Plans  Functions  (continued) 


Functions 

Systems 

EP.10.5 

Maintain  SA  of  Mission,  Tasking  &  Operational 
Environment 

DCGS-N,  C2PC 

EP.10.1 

Allocate  ISR  Resources 

JWICS 
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APPENDIX  B 

ACRONYMS  OF  ASSIGNED  SYSTEMS 


ADSI 

AESOP 

C2PC 

CANES 

CENTRIX 

CEASE 

CMA 

CNDE 

COLISEUM 

CPOF 

DCGS-N 

DJC2 

DRRS 

ExMan 

GALE 

GCCS 

GCCS-I3 

GCCS-J 

GCCS-M 

GCSS(Thin) 

GCSS-CC/JTF 

GEM 

GIANT 

ISPAN 

IWS 

JADOCS 

JCRE 

JMPS 

JSIPS 

JWS 

M3 


Air  Defense  Systems  Integrator 
Afloat  Electromagnetic  Spectrum  Operations  Program 
Command  and  Control  Personal  Computer 
Consolidated  Afloat  Networks  and  Enterprise  Services 
Combined  Enterprise  Regional  Information  Exchange  System 
Collaborative  Force  Analysis,  Sustainment,  and  Transportation 
Comprehensive  Maritime  Awareness 
Consolidated  Net  Centric  Data  Environment 

Community  On-Line  Intelligence  System  for  End  Users  and  Managers 

Command  Post  of  the  Future 

Distributed  Common  Ground  System-Navy 

Deployable  Joint  Command  and  Control 

Defense  Readiness  Reporting  System 

Exercise  Manager 

Generic  Area  Limitation  Environment 
Global  Command  and  Control  System 

Global  Command  and  Control  System-Integrated  Imagery  and  Intelligence 
Global  Command  and  Control  System-Joint 
Global  Command  and  Control  System-Maritime 
Global  Combat  Support  System 

Global  Combat  Support  System  -  Combatant  Commander/ Joint  Task  Force 

Global  Force  Manager 

GPS  Interface  and  Navigation  Tool 

Integrated  Strategic  Planning  and  Analysis  Network 

Information  Work  Space 

Joint  Automated  Deep  Operations  Coordination  System 

Joint  Collaborative  Real  Time  Engagement 

Joint  Mission  Planning  System 

Joint  Service  Imagery  Processing  System 

Joint  Warfighting  Space 

Multimedia  Message  Manager 
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MDA 

MIPS 

MSRT 

NCCT 

NCES 

NERMS 

NIPRNet 

SBMCS 

SCOPES 

SIPRNet 

SVOIP 

TDBM 

VISION 

VTC 


APPENDIX  B  (continued) 

Maritime  Domain  Awareness 

Maritime  Interdiction  Integrated  Air  and  Missile  Defense  Planning 
System 

Maritime  Support  Request  Tool 

Net-Centric  Collaborative  Targeting 

Net-Centric  Enterprise  Services 

Navy  Emergency  Response  Management  System 

Non-Classified  Internet  Protocol  Router  Network 

Space  Battle  Management  Core  System 

Space  Common  Operating  Picture  and  Exploitation  System 

Secret  Internet  Protocol  Router  Network 

Secret  Voice  Over  Internet  Protocol 

Tactical  Database  Management 

Virtual  Integrated  Support  for  Information  Operations  Environment 
Video  Teleconference 
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